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Keynote 


Dr.  Barry  M  Horowitz  is  MITRE’s 
president  and  chief  executive  officer.  He 
served  from  1987  through  1990  as 
executive  vice  president  and  chief 
operating  officer,  responsible  for  the 
general  management  and  direction  of  the 
company’s  overall  technical,  financial, 
and  administrative  activities.  Earlier,  he 
was  group  vice  president  and  general 
manager  of  the  company’s  operations  in 
Bedford,  MA,  which  are  primarily  in 
support  of  the  Air  Force.  Dr.  Horowitz 
became  a  member  of  MITRE’s  Board  of 
Trustees  in  February  1989. 

Dr.  Horowitz  joinrd  MITRE  in  1969 
at  the  company’s  Washington  Center 
located  in  McLean,  VA,  and  held  a 
succession  of  positions  from  technical 
staff  to  department  head.  Most  of  his 
effort  was  devoted  to  air  traffic  control,  in 
support  of  the  FAA.  During  the  period 
from  1969  to  1979,  he  became  a 
recognized  leader  in  the  aviation 
community  on  the  design  of  new  collision 
avoidance  systems.  He  led  MITRE 
efforts,  which  initiated  the  technical 
approach  for  airborne  collision  avoidance 
systems,  currently  being  established  as 
a  national  standard.  He  also  led  MITRE 
efforts  that  have  developed  advanced 
enroute  ATC  automation  concepts  and 


designs,  and  initiated  an  activity  to  build 
a  real-time  simulation  facility  to  evaluate 
new  designs  and  concepts  for  the  FAA. 
This  effort  resulted  in  what  currently  is  a 
major  FAA  resource  for  designing 
advanced  automation  systems.  He  also 
played  a  major  role  in  the  analysis  and 
regulation  process  that  resulted  in  new 
government  standards  for  independent 
IFR  approaches  to  parallel  runways. 

During  the  period  from  1 979  to  the 
present  at  MITRE,  Dr.  Horowitz  moved  to 
the  company’s  headquarters  in  Bedford, 
MA,  and  rose  in  rank  from  Director  of 
Special  Studies  to  his  present  position. 
In  addition  to  his  management  role,  he 
has  been  a  strong  persona!  contributor  to 
a  wide  variety  of  initiatives  in  the  area  of 
strategic  command  and  control.  He  is  a 
national  authority  on  techniques  for 
managing  engineering  programs. 

Dr.  Horowitz  received  a  BS  in 
Electrical  Engineering  from  City  College 
of  New  York  in  1965,  an  MS  in  Electrical 
Engineering  from  New  York  University  in 
1969. 
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Acquisition  Panel 


LTG  Alonzo  E.  Short,  Jr. 

Director,  Defense  Information  Systems  Agency 
Manager,  National  Communications  System 


Lieutenant  General  Alonzo  E.  Short,  Jr. 
was  born  in  Greenville,  NC  on  27 
January  1939.  He  grew  up  in 
Portsmouth,  VA,  where  he  attended  I.C. 
Noreom  High  School.  General  Short 
holds  a  BS  in  education  from  Virginia 
State  College  and  an  MS  in  business 
management  from  New  York  Institute  of 
Technology,  Long  Island,  NY.  He  also 
holds  honorary  doctorates  from  Virginia 
State  University  and  C.H.  Mason 
University,  San  Diego,  CA.  His  military 
education  includes  completion  of  the 
Signal  Officer  Basic  and  Advanced 
Courses,  the  Armed  Forces  Staff 
College,  the  Communications-Electronics 
Systems  Engineer  Course,  and  the  Army 
War  College. 

Since  entering  the  Army  in  June  of 
i  1 962,  General  Short  has  held  a  variety  of 

|  assignments  with  progressively 

\  increasing  responsibility  throughout  his 

career. 

In  1975,  General  Short  was 
assigned  as  a  staff  officer  in  the  Defense 
Communications  Agency  (now  the 
Defense  Information  Systems  Agency). 
Following  that  assignment,  General  Short 
was  a  battalion  commander  in  the  101st 
Airborne  (Air  Assault)  Division  at  Fort 
Campbell,  KY. 

In  1979,  he  began  a  tour  as  a  staff 


planner  with  the  Army  Communications 
Command  at  Fort  Huachuca.  He  then 
served  as  Commander  of  the  3rd  Signal 
Brigade  at  Fort  Hood,  TX. 

The  General  was  then  assigned 
as  the  Deputy  Commander  of  the  Army 
Electronics  Research  and  Development 
Command  (ERADCOM),  Adelphi,  MD, 
from  July  1984  to  October  1984. 

General  Short  was  promoted  to 
Brigadier  General  concurrent  with 
assuming  command  of  the  Information 
Systems  Management  Activity  (ISMA) 
while  at  the  same  time  taking  over  as 
Program  Manager  for  Army  Information 
Systems,  all  at  Fort  Monmouth,  NJ.  In 
July,  1986,  he  became  Deputy 
Commander  of  the  Informations  Systems 
Engineering  Command  (ISEC),  and 
Commander  in  September  1987. 

General  Short  was  promoted  to 
Major  General  when  he  became 
Information  Systems  Command  Deputy 
Commander  on  7  September  1988. 
General  Short  then  assumed  command 
of  the  Information  Systems  Command  in 
June  1990  and  was  promoted  to 
Lieutenant  General  at  the  same  time. 

In  August  1991,  General  Short 
became  Director,  Defense  Information 
Systems  Agency/Manager,  National 
Communications  System. 
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Donald  E.  MulHkln 

Deputy  Program  Manager  for  Advanced  Automation,  AAP-2A 
Federal  Aviation  Administration 


Donald  Mullikin  is  Deputy  Program 
Manager  tor  Advanced  Automation,  AAP- 
2A.  Over  a  20  year  period,  Dr.  Mullikin 
held  key  technical,  program/project 
management,  and  senior  management 
positions  in  the  Department  of  Navy  and 
the  Defense  Intelligence  Agency.  He 
Joined  the  FAA  in  November  of  1984  and 
served  in  several  technical  and 
management  positions  in  the  Program 
Engineering  Service.  He  joined  the 
Advanced  Automation  Program  in  June 
1988. 

Dr.  Mullikin  holds  a  DS  in 
Electrical  Engineering,  an  MS  in 
Electrical  Engineering  and  PhD.  in 
Electrical  Engineering. 

Prior  to  his  current  position,  Dr. 
Mullikin  was  the  Assistant 
Manager/Manager,  Advanced  Automation 
Systems  (AAS)  Division,  Automation 
Service,  Advanced  Automation  Program, 
FAA,  Washington,  DC.  From  July  1987 
to  July  1988,  he  was  Assistant  Manager, 
Facilities  Integration  Division,  Program 
Engineering  Service,  FAA,  Washington 
DC.  From  November  1984  to  July  1987, 
Technical  Advisor  to  Director,  Program 
Engineering  and  Maintenance  Service, 
FAA,  Washington,  DC, 

From  April  1981  to  November 


1984,  he  was  Assistant  Deputy  Director 
for  Defense  Intelligence  Systems, 
Washington  DC.  From  June  1973  to 
April  1984,  he  was  Assistant  Manager, 
C3  Project  Office,  Naval  Electronics 
System.  Washington  DC.  From 
November  1968  to  June  1973,  he  was 
Systems  Engineer,  Command  Support 
Division,  ASW  Systems  Project  Office, 
Washington,  DC.  From  September  1966 
to  November  1968,  he  was  Electronics 
Engineer,  Sonar  Project  Office,  Naval 
Ship  Systems  Command,  Washington, 
DC.  From  June  1964  to  September 
1966,  he  was  an  Engineer  Trainee, 
System  Effectiveness  Sector),  Naval 
Ship  Engineering  Center,  Washington, 
DC.  From  September  1962  to  February 
1964,  he  was  an  Engineering  Assistant. 
Data  Processing  Division,  Department  of 
Commerce  Bureau  of  Census,  Suitland, 
MD. 
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LTG  Peter  A.  Kind 

Director  of  Information  Systems  for  Command,  Control, 
Communications  and  Computers,  Office  of  the  Secretary  of  the  Army 


Lieutenant  General  Peter  A.  Kind  Is  a  native 
of  Wisconsin.  Upon  completion  of  studies  at 
the  University  of  Wisconsin  In  1961 ,  he  was 
commissioned  a  Second  Lieutenant  and 
awarded  a  BS  in  Economics.  He  also  holds 
a  MBA  from  Harvard  University.  His  military 
education  includes  the  Basic  Officer  Course 
at  the  Signal  School,  the  Communications 
Officer  Course  offered  at  the  US  Marine 
Corps  Amphibious  Warfare  School,  the  US 
Army  Command  and  General  Staff  College 
and  the  US  Army  War  College. 

He  was  assigned  to  the  97th  Signal 
Battalion  (Army),  10th  Special  Forces  Group 
(Airborne)  In  Germany  and  as  Signal  Advisor 
to  the  21st  Infantry  Division  (Air  Assault)  in 
Vietnam. 

Following  duty  as  Assistant  Division 
Signal  Officer  of  the  82d  Airborne  Division 
and  as  Executive  Officer  and  S2/S3 
(Intelligence/Operations  and  Training)  for  the 
82d  Signal  Battalion,  Fort  Bragg,  NC,  he 
served  In  the  War  Plans  Division  of  the 
Office  of  the  Deputy  Chief  of  Staff  for 
Operations  and  Plans,  Headquarters, 
Department  of  the  Army.  He  commanded 
the  1st  Calvary  Division’s  13th  Signal 
Battalion,  Fort  Hood,  TX  and  studied  at  the 
Logistics  Management  Center’s  School  of 
Management  Science.  General  Kind  then 
served  as  Chief  of  the  Concepts  and  Studies 
Division,  Directorate  of  Combat 
Developments  at  the  Signal  Center  prior  to 
Army  War  College  attendance. 


He  then  served  as  Commander  of  the 
1st  Signal  Brigade  with  concurrent  duty  as 
the  Assistant  Chief  of  Staff,  J6,  US  Forces  In 
Korea  and  G-6,  Eighth  US  Army;  as  Director 
of  Combat  Development,  and  as  Deputy 
Commanding  General  and  Assistant 
Commandant,  US  Army  Signal  Center  and 
School,  Fort  Gordon,  GA.  He  served  as 
Deputy  Controller  of  the  NATO  Integrated 
Communications  System  Central  Operating 
Authority,  NATO’s  equivalent  to  the  US 
Defense  Communications  Systems, 
headquartered  at  SHAPE,  Belgium,  and  then 
as  Program  Executive  Officer,  Command 
Control  Systems,  Fort  Monmouth,  NJ. 

He  then  served  as  Commanding 
General,  US  Army  Signal  Center  and  Fort 
Gordon  Commandant,  US  Army  Signal 
School,  Fort  Gordon,  GA  and  as 
Commanding  General,  US  Army  Information 
Systems  Command,  Fort  Huachuca,  A Z  prior 
to  hls  present  assignment  as  Director  of 
Information  Systems  for  Command,  Control, 
Communications  and  Computers,  Office  of 
the  Secretary  of  the  Army,  Washington,  DC. 

General  Kind  has  been  awarded  the 
Distinguished  Service  Medal,  the  Legion  of 
Merit  (with  Oak  Leaf  Cluster),  the  Bronze 
Star  Medal  (with  2  Oak  Leaf  Clusters),  the 
Meritorious  Service  Medal  (with  2  Oak  Leaf 
Clusters),  Air  Medals,  Army  Commendation 
Medal  and  Senior  Parachutist  Badge. 


Keynote  Speaker 


Gerald  W.  Ebker 
Vice  President,  IBM 
CEO,  IBM  Federal  Systems 


Gerald  W.  Ebker  is  chairman  and  chief 
executive  office  of  the  IBM  Federal 
Systems  Company.  The  company  was 
formed  in  March  1992  and  is  responsible 
for  IBM’s  operations  with  the  federal 
government.  It  is  one  of  several  IBM 
companies  operating  as  independent 
business  units.  FSC  is  a  major  provider 
of  custom  systems  integration  solutions, 
services  and  product  offerings  to 
government  customers. 

Mr.  Ebker  joined  IBM  Federal 
Systems  Division  in  1963  as  a 
programmer  on  the  Apollo  space 
program  at  IBM  Houston.  Until  1973,  he 
held  a  number  of  management  positions 
while  assigned  to  the  space  program. 

From  1973  until  1976,  he  was 
program  manager  of  the  IBM  advanced 
control  system  project  for  automating  oil 
refineries.  In  1977,  Mr.  Ebker  was 
named  manager  of  software  systems  at 
IBM  Manassas,  and  in  1979  became 
general  manager  of  FSD’s  facility  in 
Gaithersburg,  MD. 


In  1981,  he  was  nalmed  FSD  vice 
president,  Defense  and  Space  Systems, 
and  in  1983  he  became  FSD  vice 
president,  Complex  Systems.  He  was 
named  president  of  the  Federal  Systems 
Division  in  January  1987  and  became  an 
IBM  vice  president  in  February  1988.  He 
was  named  president  of  the  Systems 
Integration  Division  in  April  1988  and 
became  president  of  the  Federal  Sector 
Division  in  April  1990.  j 

Mr.  Ebker  was  named  to  his 
present  position  in  March  1 1992. 

In  June  1992,  he  was  elected  to 
serve  a  one-year  term  as  chairman  of  the 
Armed  Forces  Communications  and 
Electronics  Association. 

Mr.  Ebker  has  a  BS  in 
Mathematics  from  Harding  College  and  a 
MS  in  Mathematics  from  Kansas  State 
University. 
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Luncheon  Speaker 


Supply  Corps,  United  States  Navy 
Commander,  Naval  Information  Systems  Management  Center 


Rear  Admiral  Robert  M.  Moore  is 
Commander,  Naval  Information  Systems 
Management  Center.  His  responsibilities 
include  information  resources  (IR)  planning 
and  policy  related  to  the  Department's 
multibillion  dollar  information  resources 
budget.  Additionally,  he  oversees  IR-related 
programs,  insertion  of  new  technology,  and 
acquisition  of  information  resources. 

A  native  of  San  Antonio,  TX,  he 
received  a  BS  from  the  University  of  Texas 
and  a  MBA  from  Harvard  University. 

Commissioned  in  1961,  his  early 
tours  included  $upply  Officer  of  the 
Destroyer  HYMAN  and  instructor  at  the  Navy 
Supply  Corps  School  at  Athens,  GA.  In 
1964  he  was  selected  for  duty  in  the  Naval 
Nuclear  Propulsion  Program  and  in  1966 
was  assigned  as  the  program's  contracting 
officer  at  a  division  of  the  General  Electric 
Company  at  Schenectady,  NY. 

From  1971  to  1973  RADM  Moore 
served  as  Director,  Nuclear  Equipment 
Support  Division  at  the  Navy's  Ships  Parts 
Control  Center,  Mechanicsburg,  PA,  and 
following  this,  served  a  second  tour  in  the 
Naval  Nuclear  Propulsion  Program  where  he 
was  in  charge  of  -the  headquarters 
procurement  and  new  construction  budget 
functions. 

He  served  as  Supply  Officer  of  the 
Submarine  Tender  HOLLAND  at  Submarine 
Refit  Site  One,  Holy  Loch,  Scotland,  from 


1979  through  1981.  He  then  served  as 
Assistant  for  Program  and  Budget,  Attack 
Submarine  Division,  Office  of  the  Deputy 
Chief  of  Naval  Operations  (Submarine 
Warfare). 

In  July  1983,  RADM  Moore  became 
the  Vice  Commander,  Navy  Accounting  and 
Finance  Center,  Washington,  DC. 

In  July  1985,  he  assumed  command 
of  the  Navy  Fleet  Material  Support  Office, 
Mechanicsburg,  PA.  As  the  Senior 
Executive  of  the  Navy's  largest  Data 
Processing  System  Development  Center,  his 
duties  included  direct  responsibility  for  three 
of  the  largest  Data  Processing  projects  ever 
undertaken  in  the  Federal  Sector. 

His  first  tour  as  a  flag  officer  was 
Competition  Advocate  General  of  the  Navy. 
RADM  Moore  was  the  Assistant  Commander 
for  Inventory  and  Systems  Integrity,  Naval 
Supply  Systems  Command  from  July  1988  to 
June  1991.  He  was  responsible  for  Navy 
Programs  to  upgrade  and  modernize  the 
Navy  Supply  Systems  which  supports  the 
fleet  throughout  the  world  and  led  the 
program  to  insure  the  accuracy  and  integrity 
of  the  Navy’s  multibillion  dollar  logistics 
support  inventories. 

RADM  Moore's  military  decorations 
include  the  Legion  of  Merit  (five  awards)  and 
the  Meritorious  Service  Medal  (two  awards). 
He  is  also  qualified  in  submarines. 


Acquisition  Panel 


Moderator:  LTG  Alonzo  E.  Short,  DISA 
Panelists: 
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FAST  ANALYTICAL  SIMULATION 
OF  MISSILE  FLIGHTS 

Yuh-jeng  Lee  John  V.  Waite 

Computer  Science  Department  Pacific  Missile  Test  Center 

Naval  Postgraduate  School  Code  1051 

Code  CS/LE  Point  Mtigu  CA  93042 

Monterey  CA  93943 


Abstract 

We  present  an  air-to-air  missile  flight  simulation 
that  has  been  designed  and  developed  using  the 
Ada  programming  language  with  the  object  ori¬ 
ented  methodology.  It  was  aimed  at  providing 
a  test  and  evaluation  method  that  is  more  un¬ 
derstandable,  modifiable,  efficient,  and  reliable 
than  earlier  FORTRAN  simulations.  The  prin¬ 
ciples  of  abstraction,  information  hiding,  modu¬ 
larity,  high  cohesion,  and  low  coupling  were  used 
to  achieve  these  goals.  The  resulting  simulation, 
a  three  degree-of-freedom  model  of  guided  air-to- 
air  missile,  is  an  accurate  mapping  of  the  problem 
space  into  software.  The  simulation  is  primarily 
intended  to  study  missile  kinematics. 

INTRODUCTION 

The  ever  increasing  cost  and  complexity  of  modern 
weapon  systems  forces  new  demands  on  the  test  and 
evaluation  (T&E)  process.  More  extensive  testing  is 
required  with  fewer  resources.  This  paper  explores  one 
aspect  of  the  T&E  process  as  it  relates  to  air-to-air 
guided  missiles. 

In  the  early  days  of  missile  T&E  ( circa  late  1940s), 
missile  performance  capability  was  determined  solely 
through  flight  test,  that  is,  actual  missile  launches. 
The  realization  that  all  the  T&E  data  requirements 
could  not  be  met  with  a  limited  number  of  launches 
led  to  captive-carry  flight  test,  laboratory  testing,  and 
simulation  to  complement  the  missile  launches.  To¬ 
day’s  data  requirements  have  grown  in  response  to  the 
increased  missile  sophistication  and  mission  complex¬ 
ity.  It  is  not  unusual  for  a  single  flight  test  to  cost 
more  than  a  million  dollars.  Due  to  the  increased  data 


requirements  and  increased  cost  of  flight  test,  missile 
flight  simulation  is  receiving  more  and  more  attention. 

Missile  Flight  Simulation 

There  are  three  levels  of  missile  flight  simulation  in 
terms  of  cost  and  complexity: 

•  Real-time  hardware-in-the-loop  (HIL)  simulation  in¬ 
tegrates  actual  missile  hardware  with  special  test 
and  instrumentation  equipment  in  a  laboratory  envi¬ 
ronment.  The  simulation  software  typically  runs  on 
a  high-speed  special  purpose  computer  that  drives 
the  test  equipment  and  missile  hardware.  The  real¬ 
time  HIL  simulation  requires  a  major  development 
effort  of  approximately  thirty-five  to  forty  man  years 
and  costs  from  five  to  ten  mdlion  dollars1. 

•  The  second  level  of  simulation  is  the  all  digital  six- 
degree-of-freedom  (6-DOF)  missile  flight  simulation. 
Six-degree-of-freedom  indicates  that  the  simulation 
computes  forces  and  moments  for  all  three  axes.  The 
6-DOF  simulation  incorporates  sophisticated  mod¬ 
els  for  various  missile  subsystems  and  runs  on  a 
mainframe  class  computer.  The  6-DOF  runs  many 
times  slower  than  real-time.  For  example,  an  ac¬ 
tual  missile  flight  that  might  take  thirty  seconds  to 
complete  in  real-time  might  take  eighteen  hours  to 
run  to  completion  using  a  6-DOF  simulation.  The 
6-DOF  simulation  requires  a  development  effort  of 
four  to  six  man  years. 

•  The  third  level  of  simulation,  the  main  focus  of  this 
paper,  is  the  fast  analytical  simulation  (FAS).  Sim¬ 
ulations  of  this  class  are  a  rapid  and  inexpensive 
tool  allowing  missile  systems  analysts  to  study  over¬ 
all  missile  response  or  capability  expeditiously.  The 
FAS  is  a  three  degree-of-freedom  (3-DOF)  simula¬ 
tion,  usually  the  forces  are  computed  for  all  three 


axes  (the  moments  are  ignored)  and  a  three  di¬ 
mensional  space  is  represented.  Alternately,  a  3- 
DOF  might  represent  a  planar  two  dimensional  view 
where  forces  acting  on  two  axes  are  computed  while 
moments  are  computed  about  the  remaining  axis. 
The  FAS  is  intended  to  be  easily  accessible  via  per¬ 
sonal  computers  to  provide  results  in  a  timely  fash¬ 
ion.  A  user  enters  initial  conditions  and  results  are 
presented  within  a  few  minutes. 

Current  Practices:  Problems  and 
Limitations 

Current  simulations  are  usually  developed  by  physi¬ 
cists  or  aerospace  engineers  (who  usually  have  lit¬ 
tle  or  no  training  and  knowledge  in  modern  software 
engineering  principles),  using  the  FORTRAN  pro¬ 
gramming  language.  Their  main  goal  is  “just  to  get 
something  up  and  running”.  The  resulting  simula¬ 
tions  are  almost  always  poorly  structured  and  vio¬ 
late  most  commonly  accepted  computer  programming 
principles.  Typical  characteristics  of  these  simulations 
are: 

•  The  simulations  are  monolithic  pieces  of  code  using 
many  GOTO  statements; 

•  most  variables  are  treated  as  global; 

•  Common  data  areas  are  used  for  communication  be¬ 
tween  subroutines; 

•  cryptic  variable  names  are  used  (FORTRAN  vari¬ 
able  names  are  limited  to  six  characters); 

•  the  simulations  are  limited  to  very  simple  data  struc¬ 
tures  (multi-dimensional  arrays  are  usually  the  most 
sophisticated  data  structures  found); 

•  programming  through  side  is  common;  and 

•  the  simulations  have  little  or  no  comments  or  formal 
documentation. 

The  new  analyst  will  usually  require  at  least  six 
months  to  gain  a  basic  understanding  of  how  the  sim¬ 
ulation  works,  even  if  he  or  she  has  an  excellent  un¬ 
derstanding  of  missile  systems.  An  understanding  of 
the  simulation  is  critical  if  results  are  to  be  interpreted 
correctly.  It  is  not  uncommon  for  the  original  devel¬ 
opers  of  a  simulation  to  move  on  to  other  jobs,  leaving 
the  analysts  responsible  for  maintaining  and  modify¬ 
ing  the  simulation.  Changes  in  the  production  mis¬ 
sile’s  software  or  hardware,  regularly  occurring  events, 
must  be  accurately  reflected  in  the  simulation  code. 
Changes  or  patches  introduced  to  the  simulation  code 
invariably  make  the  code  more  obscure  and,  more  of¬ 
ten  than  not,  produce  undesirable  side  affects  or  bugs. 
Debugging  these  types  of  problems  is  incredibly  time 
consuming  and  difficult. 

After  numerous  patches  have  been  applied  the  sim¬ 
ulation  software  becomes  unreliable  and  inefficient. 


Wildly  different  results  are  obtained  for  slightly  differ¬ 
ent  initial  conditions.  The  real-time  HIL  simulations 
no  longer  run  in  real-time.  The  6-DOF  simulations 
may  take  days  to  solve  a  problem  and  the  3-DOF  FAS 
simulations  take  hours  -  what  once  required  hours  and 
minutes  respectively.  Disk  and  main-memory  capacity 
become  issues.  What  was  once  a  tool  enabling  scien¬ 
tists  and  engineers  to  analyze  complex  systems  has  be¬ 
come  an  unwieldy  demanding  burden  of  questionable 
value. 

Consequently,  they  are  difficult  to  understand  and 
modify,  and  inevitably  become  inefficient  and  unreli¬ 
able. 

Motivation  and  Goals 

Given  the  current  situation,  what  is  needed  is  a 
method  that  more  closely  represents  the  problem 
space,  allowing  simulations  to  be  developed  that  are 
easy  to  understand  and  modify. 

The  major  purpose  of  this  project  is  to  explore  the 
use  of  object  oriented  techniques  using  the  Ada  pro¬ 
gramming  language,  in  conjunction  with  contempo¬ 
rary  software  engineering  principles,  to  implement  a 
missile  flight  simulation.  This  simulation  should  be 
easily  understood  in  a  reasonable  amount  of  time  and 
readily  accommodate  change.  Additional  goals  include 
producing  code  that  is  efficient  and  reliable. 

The  Approach 

We  have  designed  and  developed  a  fast  analytical  sim¬ 
ulation  (FAS)  program,  written  in  Ada,  which  is  aimed 
at  providing  a  reliable  and  inexpensive  tool  that  al¬ 
lows  missile  systems  analysts  to  study  overall  missile 
response  or  capability  expeditiously.  The  missile  flight 
simulation  models  a  subset  of  the  missile  systems  (in¬ 
cluding  the  Autopilot,  Airframe,  and  Guidance),  the 
kinematics  (consisting  of  the  missile  dynamics  and  the 
missile-target  geometry),  and  the  target.  At  the  top 
level  view,  the  simulation  computes  the  forces  acting 
on  the  missile  (e.g.,  thrust,  drag,  and  gravity)  and  from 
these  forces  derives  accelerations  to  compute  the  mis¬ 
sile’s  spatial  trajectory  from  launch  to  target  intercept. 

By  adhering  to  object-oriented  design  principles  (in¬ 
cluding  abstraction,  inheritance,  information  hiding, 
modularity,  high  cohesion  and  low  coupling),  the  re¬ 
sult  is  an  accurate  mapping  of  the  problem  space  into 
software.  Since  the  mapping  preserves  the  real  world 
view  of  the  problem,  we  believe  that  our  simulation 
program  is  more  understandable,  modifiable,  efficient, 
and  dependable  than  earlier  FORTRAN  simulations. 

OBJECT-ORIENTED  TECHNIQUES 
WITH  ADA 

The  goal  of  object  oriented  techniques  is  to  produce 
software  that  is  understandable,  easy  to  modify,  effi- 


9  1  1  rK  Annual  -n,l  f1——  —  — 


AJ.  »r 


i  t\n  ** 


cient,  reliable,  and  reusable.  Each  of  these  character¬ 
istics  is  elaborated  below: 

Understandability:  This  is  critical  to  the  manage¬ 
ment  of  complex  software  systems.  It  is,  without  a 
doubt,  the  most  important  factor  of  a  simulation  to 
the  analyst  responsible  for  maintaining  the  simula¬ 
tion.  The  software  solution  (that  is,  the  simulation) 
should  be  an  accurate  model  of  the  real  world  prob¬ 
lem.  Software  can  be  thought  of  as  being  under¬ 
standable  on  both  a  micro  and  macro  level.  Code 
at  the  micro  level  should  have  a  style  that  is  very 
readable.  At  the  macro  level  data  structures  and  al¬ 
gorithms  should  be  able  to  be  identified  as  mapping 
from  the  real  world  problem  space.  Understandabil¬ 
ity  also  tends  to  be  tied  to  the  programming  lan¬ 
guage  used  and  its  richness  of  expression. 

Modifiability:  Well  designed  software  should  readily 
permit  change.  Modification  is  usually  required  due 
to  a  change  in  requirements  or  to  correct  to  an  error. 
Changes  in  missile  simulation  code  are  required  to 
explore  new  concepts,  or  as  a  result  of  missile  hard¬ 
ware  or  software  upgrades.  Many  changes  are  not 
planned.  Ideally,  changes  should  not  alter  the  fun¬ 
damental  architecture  of  the  software  solution. 

Efficiency:  Efficiency  is  the  optimal  use  of  two  fun¬ 
damental  computer  resources  -  storage  space  and 
execution  time.  Both  of  these  resources  arc  depen¬ 
dent  underlying  hardware,  yet  both  resources  arc 
equally  dependent  on  the  software.  An  efficient  mis¬ 
sile  simulation  should  provide  better  user  response 
and  more  functionality  than  an  inefficient  simula¬ 
tion. 

Reliability:  The  goal  of  reliability  is  to  prevent  fail¬ 
ure,  and  to  some  extent,  recover  from  failure  in  a 
graceful  manner.  Failure  in  a  missile  simulation 
might  be  defined  as  anything  from  a  program  that 
crashes  to  a  program  that  produces  results  that  do 
not  agree  with  flight  test  data  or  produces  inconsis¬ 
tent  results.  A  reliable  missile  simulation  will  pro¬ 
vide  results  that  are  consistent  with  real  world  ex¬ 
periences  and  give  meaningful  indications  when  po¬ 
tential  problems  might  arise  (e.g.,  limits  exceeded  or 
incorrect  user  input). 

Reusability:  The  goal  of  reusability  is  to  provide 
software  components  to  build  software  much  the 
same  way  hardware  engineers  build  circuits  from 
standard  off-the-shelf  components.  The  develop¬ 
ment  of  software  systems  can  be  dramatically  re¬ 
duced  by  using  software  components  that  have  al¬ 
ready  been  debugged  and  tested.  These  components 
can  form  libraries  of  commonly  used  objects.  Sys¬ 
tems  may  be  constructed  from  these  libraries.  These 
systems  then  may  be  added  to  the  library. 


Object-Oriented  Principles 
Through  abstraction,  information  hiding  and  modular¬ 
ity,  object  oriented  techniques  encapsulates  data  and 
procedural  abstractions  to  form  objects.  Objects  mod¬ 
ularize  both  information  and  processing,  rather  than 
processing  alone.  Object  oriented  techniques  establish 
a  mechanism  for  (1)  a  representation  of  data  struc¬ 
tures,  (2)  the  specification  of  process,  and  (3)  the  in¬ 
vocation  procedure.  An  object  is  an  element  of  the  real 
world  mapped  into  the  software  domain.  The  object 
consists  of  operations  which  act  on  data  structures  in 
response  to  messages  sent  to  that  object  from  other 
objects.  The  operations  and  data  structures  are  hid¬ 
den,  that  is  the  implementation  details  are  unknown 
to  the  user  of  the  object.  The  interface  to  the  object 
is  the  only  portion  visible  to  the  user.  The  interface 
is  a  set  of  well  defined  messages  that  specify  what  op¬ 
eration  on  the  object  is  desired.  Object  oriented  tech¬ 
niques  can  aid  sound  software  engineering  principles. 
These  principles  include  abstraction,  information  hid¬ 
ing,  modularity,  loose  coupling,  and  strong  cohesion2. 

Abstraction.  Many  of  the  problems  found  with  the 
missile  flight  simulations  are  due  to  their  complexity. 
Abstraction  is  a  powerful  concept  that  helps  one  deal 
with  complexity.  Abstraction  concentrates  on  the  es¬ 
sential  aspects  of  a  problem,  while  omitting  the  details. 
There  may  be  many  levels  of  abstraction  constructed 
when  solving  a  problem.  At  the  top  level  of  a  missile 
simulation,  abstraction  would  reveal  the  essential  en¬ 
tities  -  the  missile,  target,  and  environment.  Moving 
to  the  next  lower  level  of  abstraction  within  the  mis¬ 
sile,  this  level  might  be  thought  of  as  being  composed 
of  various  subsystems,  such  as  the  seeker,  the  guid¬ 
ance  section,  the  autopilot,  and  the  airframe.  Mov¬ 
ing  to  the  next  lower  level  of  abstraction,  arbitrarily 
choosing  the  missile  seeker  for  example,  would  reveal 
the  data  structures  and  procedures  used  to  model  the 
seeker.  Only  the  lower  levels  of  abstraction  expose  the 
specific  details  of  a  solution. 

Information  Hiding.  Information  hiding  conceal- 
the  implementation  details  of  a  solution  that  should 
not  affect  other  parts  of  a  system.  Through  informa¬ 
tion  hiding  only  the  essential  aspects  of  a  solution  are 
visible,  while  the  implementation  details  or  “how"  of  a 
solution  are  hidden.  Hiding  low  level  design  decisions 
prevents  the  higher  levels  of  abstraction  from  being 
dependent  on  implementation  details.  This  approach 
aids  abstraction  and  increase  the  modifiability  of  the 
solution. 

Modularity.  The  importance  of  modularity  in  soft¬ 
ware  design  has  been  recognized  for  some  time.  Ac¬ 
cording  to  Myers3,  “Modularity  is  the  single  attribute 
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of  software  that  allows  a  program  to  be  intellectually 
manageable.”  In  monolithic  software,  such  as  the  mis¬ 
sile  simulations,  the  number  of  control  paths,  num¬ 
ber  of  variables  and  the  overall  complexity  make  un¬ 
derstanding  difficult.  Ideally,  software  is  decomposed 
into  modules  along  logically  and  functionally  indepen¬ 
dent  lines.  Modularity  supports  our  notion  of  abstrac¬ 
tion.  High-level  modules  specify  “what”  is  to  be  done. 
Low-level  modules  specify  “how”  that  action  is  to  take 
place. 

Cohesion  and  Coupling.  Modules  in  software  sys¬ 
tems  can  be  thought  of  as  having  two  important  char¬ 
acteristics,  cohesion  and  coupling.  Cohesion  attempts 
to  characterize  to  what  degree  a  module  performs  a 
single  function  or  serves  a  single  purpose.  A  highly 
cohesive  module  would  be  one  in  which  the  module 
performs  a  single  task  that  requires  little  or  no  inter¬ 
action  with  other  modules  ir.  a  program.  A  module 
exhibiting  low  cohesion  would  perform  many  different 
functions  and  interact  with  a  large  number  of  other 
modules.  Modules  that  are  highly  cohesive  arc  easier 
to  understand  and  are  more  amenable  to  change  than 
modules  exhibiting  low  cohesion. 

Coupling  is  measure  of  interconnection  among  mod¬ 
ules  in  a  program.  Modules  with  high  coupling  have  a 
complex  interfaces  and  make  use  of  data  or  control  in¬ 
formation  found  in  other  modules.  Modules  with  low 
coupling  have  relatively  simple  interfaces  and  make 
use  of  only  the  data  or  control  information  presented 
by  the  interfaces  of  other  modules.  Changes  made  to 
modules  with  low  coupling  are  less  likely  to  cause  un¬ 
wanted  effects  in  other  modules,  that  is  the  ripple  ef¬ 
fect  is  minimized.  Like  modules  that  are  highly  cohe¬ 
sive,  modules  with  low  coupling  are  easier  to  under¬ 
stand  and  modify. 

Inheritance.  Inheritance  is  an  object  oriented  con¬ 
cept  that  permits  the  organization,  building  and  reuse 
of  software4.  In  a  limited  view  of  this  concept,  new 
objects  may  be  defined  to  inherit  the  capability  and 
functionality  of  other  previously  defined  objects.  The 
new  objects  may  extend  the  capability  and  function¬ 
ality  of  the  original  object  by  adding  new  capabilities 
and  functionalities.  Conversely  the  new  object  may 
be  defined  to  eliminate  or  limit  certain  capabilities  of 
the  original  object.  Once  an  object  has  been  devel¬ 
oped,  it  may  be  reused  with  minimal  effort  through 
inheritance,  reducing  development  time. 

Object  Oriented  Methodology  with  Ada 

Object  oriented  techniques  build  on  sound  software 
engineering  principles  to  encapsulate  data  and  proce¬ 
dures  into  objects.  They  rapture  the  real  world  prob¬ 


lem  space,  map  well  into  the  Ada  programming  lan¬ 
guage. 

Ada  Packages.  The  object  orienteu  philosophy 
maps  well  into  the  Ada  programming  language.  Ada 
has  a  wide  set  of  constructs  for  providing  primitive  ob¬ 
jects  and  operations.  These  constructs  serve  to  builtl 
the  implementation  level  of  the  objects.  Ada’s  pack¬ 
aging  concept  is  conceptually  similar  to  objects  and 
provides  the  means  to  encapsulate  objects.  According 
to  Booch8,  “A  package  is  a  collection  of  computational 
resources,  which  may  encapsulate  data  types,  data  ob¬ 
jects,  subprograms,  tasks  or  even  other  packages.”  An 
Ada  package  consists  of  a  specification  and  a  body". 
The  specification  identifies  the  information  that  is  visi¬ 
ble  to  the  user  of  that  package.  The  package  body  con¬ 
tains  the  implementation  details  of  the  package  which 
should  (and  can)  remain  physically  and  logically  hid¬ 
den  from  the  user.  The  specification  and  body  may  be 
compiled  separately  to  enforce  the  separation  of  tin- 
specification  or  interface  from  the  body  with  its  im¬ 
plementation  details.  The  specification  can  serve  to 
define  the  messages  associated  with  an  object.  Tin- 
object  responds  in  the  appropriate  manner  to  these 
messages.  These  messages  might  map  to  function  or 
procedure  calls  and  their  input  or  output  variables. 

Ada  packages  can  be  used  to  provide  reusable  soft¬ 
ware  components.  Packages  of  commonly  required  ob¬ 
jects  can  form  libraries  where  they  may  be  withdrawn 
and  reused.  Ada’s  generic  unit  feature  supports,  in 
a  limited  way,  the  object  oriented  principle  of  inheri¬ 
tance.  A  generic  package  serves  as  a  template  for  an 
object7.  The  generic  object  can  then  be  instantiated 
with  all  the  features  of  the  generic  object,  along  with 
any  additional  features  required  of  that  particular  in¬ 
stantiation.  For  example,  a  generic  stack  or  list  object 
might  be  instantiated  for  each  occurrence  of  a  different 
data  type,  along  with  the  additional  capabilities  that 
make  sense  for  that  particular  data  type. 

Methodology.  We  used  an  object-oriented  develop¬ 
ment  technique  similar  to  that  advocated  by  Booch5 
and  first  proposed  by  Abbott8.  The  development  pro¬ 
cess  involves  five  steps: 

1.  First,  identify  the  objects  and  their  characteristics 
or  attributes  as  they  exist  in  the  problem  space.  Of¬ 
ten  a  concise  problem  statement  is  useful  in  identi¬ 
fying  objects.  The  nouns  of  the  problem  statement 
serve  to  identify  potential  objects. 

2.  The  second  step  is  to  identify  the  operations  that 
characterize  the  behavior  of  the  objects  identified 
in  the  first  step.  These  should  be  meaningful  oper¬ 
ations  that  can  be  performed  on  the  object.  Verbs 
associated  with  an  object  noun  in  the  problem  state¬ 
ment  can  aid  in  the  identification  of  meaningful 
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operations.  During  this  step  time  and  space  con¬ 
straints  are  formed  to  define  the  dynamic  behavior 
of  the  objects.  The  scope  and  ordering  of  operations 
might  be  defined  for  example. 

3.  The  third  step  is  to  establish  the  visibility  of  the 
objects  with  relation  to  one  another.  This  step  at¬ 
tempts  to  specify  what  objects  “see”,  and  what  are 
“seen”  by  a  given  object.  This  serves  to  map  the 
problem  space  into  the  objects. 

4.  The  fourth  step  is  to  define  the  interfaces  to  the 
objects.  To  do  this  an  object  specification  is  pro¬ 
duced  which  “forms  the  boundary  between  the  out¬ 
side  view  and  the  inside  view  of  an  object.”  This 
maps  directly  into  the  Ada  package  specification 
construct. 

3.  The  final  step  is  to  implement  each  object  by  de¬ 
signing  suitable  data  structures  and  algorithms  and 
to  implement  the  corresponding  interface  from  the 
fourth  step.  Also  at  this  step  it  is  important  to  re¬ 
main  aware  of  the  software  engineering  principles  of 
modularity,  high  cohesion  and  low  coupling.  Note 
that  this  whole  process  can  be  recursive,  that  is,  an 
object  might  further  be  decomposed  into  subordi¬ 
nate  objects. 

The  key  point  of  this  method  is  the  accurate  map¬ 
ping  of  the  problem  space  into  software.  This  map¬ 
ping  preserves  the  real  world  view  of  the  problem,  and 
if  done  properly,  tends  to  produce  code  that  is  eas¬ 
ily  understood.  Object  oriented  techniques  ajso  lend 
themselves  well  to  the  software  engineering  principles 
discussed  earlier.  Through  object  oriented  techniques 
and  sound  software  engineering  principles,  our  goals 
of  producing  a  missile  flight  simulation  that  is!  easy  to 
understand,  easy  to  modify,  efficient  and  reliable  can 
be  realized. 

THE  PROBLEM  SPACE 

An  air-to-air  guided  missile  is  designed  to  be  carried  on 
an  aircraft  and  launched  at  an  airborne  target.  After 
launching  the  missile  guides,  using  its  sensors,  on  the 
target  to  intercept.  Air-to-air  missile  sensors  may  be 
radar,  infrared  or  a  combination  of  both  types.  Once 
the  missile  detects  the  target,  it  tracks  and  guides  on 
the  target  by  generating  steering  commands  that  will 
set  a  course  to  intercept  the  target.  The  missile  flight 
simulation  attempts  to  represent  or  model  the  missile 
and  its  environment. 

The  missile  flight  simulation  models  a  subset  of  the 
missile  systems,  the  kinematics,  and  the  target.  At  the 
top  level  view,  the  simulation  computes  the  forces  act¬ 
ing  on  the  missile  (e.g.,  thrust,  drag,  and  gravity)  and 
from  these  forces  derives  accelerations  to  compute  the 
missile’s  spatial  trajectory  from  launch  to  target  inter¬ 
cept.  Figure  1  is  a  top-level  block  diagram  of  a  missile 


Figure  1:  Missile  Flight  Simulation 
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flight  simulation  indicating  the  relationships  of  the  var¬ 
ious  models.  The  missile  subsystems  are  represented 
by  the  Autopilot,  Airframe,  and  Guidance  blocks.  The 
blocks  labeled  Missile  Dynamics  and  Missile-Target 
Geometry  compute  the  kinematics.  The  Target  block 
here  represents  a  single  target,  but  in  most  simulations 
more  than  one  target  is  modeled.  The  missile  airframe 
model,  given  its  achieved  accelerations,  computes  the 
forces  acting  on  it  for  use  in  the  kinematics  model.  The 
kinematics  model  calculates  missile  dynamics  and  the 
missile-target  geometry,  which  is  passed  to  the  guid¬ 
ance  model  Acceleration  commands,  which  wilt  en¬ 
able  the  missile  to  intercept  the  target,  are  computed 
by  the  guidance  model  and  provided  to  the  autopi¬ 
lot.  TH  auiopilot  responds  with  the  achieved  acceler¬ 
ations,  which  are  passed  to  the  airframe  model. 

The  Airframe 

The  missile  airframe  actuates  or  deflects  the  control 
surfaces  which  steer  the  missile.  The  missile  is  mod¬ 
eled  as  a  rigid  body  and,  as  such,  body  and  control 
surface  bendings  arc  not  represented.  The  airframe  is 
represented  in  terms  of  a  reference  axes  system.  Tlircc 
force  equations  describe  the  forces  experienced  by  the 
missile  along  each  axis.  There  is  one  force  equation  for 
each  axis  as  follows: 

£F«  =  m  *  a, 

HFy  ~  m*av 

E F,  —  m  *  a. 

These  represent  Newton’s  classic  relation  that  force  p. 
the  product  of  mass  and  acceleration.  Here  we  resolve 
the  forces  into  components  along  each  missile  axis. 

These  force  equations  describe  the  dynamics  of  the 
airframe.  Aerodynamics  is  the  science  applied  to  pre¬ 
dicting  these  forces.  These  forces  are  expanded  in 
terms  of  aerodynamic  parameters  and  coefficients9. 
For  example,  the  x-axis  equation  becomes: 

EF*  =  m  * at  =  Fp  +  ( Cda  *aq*S)  +  (Cdt  *6*q  +  S) 

The  first  term  in  the  above  equation  is  the  propul¬ 
sion  force.  The  second  term  is  the  product  of  the  drag 
coefficient  for  a  given  angle  of  attack  (Cda) ,  the  angle 
of  attack  (a),  and  the  missile  reference  area  (5).  The 
third  term  is  the  product  of  the  drag  coefficient  ‘or 
f.  given  control  surface  deflection  {Cd(),  the  control 
surface  deflection  ( 6 ),  the  aerodynamic  pressure  ( q ), 
and  the  missile  reference  area  (S).  The  aerodynamic 
coefficients  are  a  function  of  angle  of  attack,  control 
surface  deflection,  roll  angle  and  mach  number.  The 
aerodynamic  parameters  and  forces  are  provided  to 
the  airframe  model  by  the  missile  dynamics  model, 
and  the  autopilot  model  provides  the  commanded  ac¬ 
celerations  as  input.  The  airframe  model  computes 
the  forces  it  is  “experiencing”  and  sends  these  values 
to  the  kinematics  model. 


Kinematics 

The  kinematics  model  serves  two  functions:  to  com¬ 
pute  missile  dynamics  and  to  compute  the  missile- 
target  geometry.  Inputs  to  the  missile  dynamics  func¬ 
tion  are  the  airframe  forces  computed  in  the  airframe 
model.  FVom  these  values,  and  from  initial  conditions, 
the  dynamics  model  derives  acceleration,  velocity,  po¬ 
sition  data,  and  flight-path  variables.  Angles,  angular 
rates,  and  accelerations  represent  the  inertial  quan¬ 
tities.  These  inertial  quantities  simulate  the  inertial 
sensor  measurements  the  missile  would  experience. 

Aerodynamic  parameters,  such  as  mach  and  veloc¬ 
ity,  arc  fed  back  to  the  airframe  model.  The  derived 
acceleration,  velocity,  and  position  variables  are  sent 
to  the  missile-target  geometry  model.  The  kinern.-ties 
model  also  transforms  data  between  the  two  reference 
coordinate  systems,  that  in,  between  the  airframe  ref¬ 
erence  system  known  as  the  body  coordinate  system 
( x ,  y,  z)  and  the  autopilot  reference  system  known  as 
the  inertial  coordinate  system  (Xa,Ya,Za). 

The  primary  purpose  of  the  missile-target  geome¬ 
try  portion  of  the  kinematics  model  is  to  compute 
the  missile- target  engagement  geometry  parameters. 
These  values  are  sent  to  the  missile  guidance  model  to 
steer  the  missile  to  the  target.  Inputs  to  the  missile- 
target  geometry  model  are  missile  acceleration,  ve¬ 
locity,  and  position  data  from  the  missile  dynamics 
model,  and  target  acceleration,  velocity,  and  position 
from  the  target  model.  These  inputs  are  used  to  com¬ 
pute  range  rate  (closing  velocity),  missile  to  target 
range,  line-of-sight  (LOS)  rate,  LOS,  and  time  of  flight. 
The  simulation  is  terminated  on  range  or  time  con¬ 
straints  determined  by  this  model.  The  computed  in¬ 
formation  is  sent  to  the  missile  guidance  model. 

Missile  Guidance 

The  guidance  model  represents  the  missile  guidance 
law  which  determines  what  trajectory  will  cause  the 
missile  to  intercept  the  target.  Missile  guidance  can  be 
classified  by  the  type  of  sensor  is  used  to  provide  tar¬ 
get  information.  Common  sensors  are  RF  (radar),  or 
infrared  (IR).  A  missile  may  use  a  combination  of  RF 
and  IR  seekers.  The  actual  missile  guidance  section 
is  very  complex  and  sophisticated,  hence,  extremely 
difficult  to  model.  Most  simple  simulations  assume  a 
perfect  guidance  section  that  uses  a  modified  propor¬ 
tional  guidance  law. 

An  important  parameter  in  guidance  is  the  line-of- 
sight  (LOS).  The  line-of-sight  is  the  direction  the  mis¬ 
sile  “looks”  in  order  to  “see”  the  target.  This  is  an 
imaginary  line  from  the  missile’s  seeker  to  the  cen¬ 
troid  of  the  target.  It  has  been  proven  that,  given 
constant  target  and  missile  velocities,  if  the  LOS  an¬ 
gle  between  the  target  and  the  missile  remains  con¬ 
stant  an  optimum  trajectory  will  be  achieved,  result- 
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ing  in  a  minimum  miss  distance1.  If  the  LOS  angle  is 
to  remain  constant  then  the  LOS  rate  must  be  zero. 
The  LOS  rate  is  computed  in  the  guidance  section  and 
multiplied  by  the  navigation  ratio  N  and  sent  to  the 
autopilot  as  commanded  accelerations  proportional  to 
the  LOS  rate;  hence,  the  term  proportional  guidance. 

The  commanded  accelerations  will  change  the  mis¬ 
sile  velocity  relative  to  the  target  velocity,  driving  the 
LOS  rate  to  zero.  The  response  of  the  guidance  sys¬ 
tem  is  determined  by  the  value  chosen  for  the  naviga¬ 
tion  ratio  N.  Most  modern  missiles  improve  upon  the 
pure  proportional  guidance  law  by  using  the  target  re¬ 
lated  information  available  through  improved  sensors 
and  increased  on  board  computing  power.  Target  re¬ 
lated  parameters  used  in  addition  to  LOS  include  tar¬ 
get  range,  velocity,  acceleration  and  time  to  intercept. 
Given  guidance  data,  the  guidance  model  computes 
the  commanded  accelerations  required  to  intercept  the 
target. 

The  Autopilot 

The  autopilot  functions  to  give  the  missile  stable  and 
controlled  flight.  The  autopilot  has  its  own  axes  refer¬ 
ence  system  (Xa,Ya,  Za).  The  airframe  motions  about 
the  autopilot  axe3  are  controlled  by  the  autopilot.  Mo¬ 
tions  about  the  Ya  and  Xa  axes  determine  missile  di¬ 
rection.  The  autopilots  fc.  these  axes  are  termed  the 
pitch  and  yaw  autopilots,  respectively. 

The  autopilot  receives  commanded  accelerations  as 
input  and  responds  with  achieved  accelerations  as  out¬ 
put.  The  achieved  accelerations  are  based  on  the  char¬ 
acteristics  of  the  autopilot  and  other  missile  subsys¬ 
tems. 

Target 

The  target  model  represents  a  simple  maneuvering  tar¬ 
get.  Inpi  .s  are  positional,  heading,  velocity,  and  type 
of  maneuver  initial  conditions.  Inertial  data  are  de¬ 
rived  from  this  data  and  output  to  the  missile-terget 
geometry  model.  More  sophisticated  target  models 
might  include  multiple  targets  and  targets  capable  of 
complex  maneuvers. 

The  Atmosphere 

The  Earth’s  atmosphere  is  a  dynamically  changing  sys¬ 
tem,  within  which  the  missile  must  operate.  The  pres¬ 
sure,  density  and  temperature  of  the  atmosphere  de¬ 
pend  on  altitude,  location  on  the  globe,  the  time  of  day 
and  the  season.  In  order  to  have  a  common  reference 
atmosphere,  a  standard  atmosphere  has  been  defined 
by  the  U.S.  Air  Force*.  The  standard  atmosphere  gives 
mean  values  of  pressure,  density,  and  temperature  as 
a  function  of  altitude.  Most  missile  flight  simulations 
model  the  standard  atmosphere. 


THE  SIMULATION 

The  models  described  in  the  previous  section  become 
the  Ada  objects  in  the  object  oriented  approach.  The 
relatione  between  the  models  are  represented  by  mes¬ 
sages  between  the  objects.  These  messages  can  request 
actions  of  objects  or  be  in  response  to  message  requests 
for  action.  Objects  may  be  constructed  from  other  ob¬ 
jects.  For  example,  a  missile  is  composed  of  objects 
that  represent  subsystems.  This  approach  results  in  a 
simulation  that  accurately  maps  the  problem  space  to 
software,  as  illustrated  below. 


•  The  APPLICATION  object  has  the  knowledge  of 
the  specific  details  of  the  application  in  terms  of 
what  objects  exist  and  their  interfaces.  In  our  sim¬ 
ulation,  this  object  is  responsible  for  initializing  the 
system,  starting  and  manipulating  the  simulation 
operations,  and  logging  data.  It  also  sends  messages 
to  the  MISSILE  and  TARGET  objects,  requiring 
them  to  compute  the  mathematical  derivatives  that 
characterize  them. 

•  The  USERJNTERFACE  object  is  required  for  user 
input  and  output.  It  allows  the  user  to  the  user 
to  control  the  simulation  through  keyboard  input, 
along  with  presenting  run-time  displays  and  simula¬ 
tion  status  information  to  the  user. 

The  System  Objects 

The  system  objects  includes  the  missile,  launcher,  and 
target  objects.  The  launcher  object  provides  the  mis¬ 
sile  with  launch  aircraft  information  and  targets  pro¬ 
vides  target  information. 

One  of  our  major  software  engineering  goals,  un- 
derstandability,  is  achieved  by  implementing  and  dis¬ 
cussing  the  core  of  the  simulation  in  terms  of  modular 
objects.  This  approach  also  serves  to  accurately  map 


The  Control  Objects 

At  the  highest  level  of  abstraction,  we  wish  to  keep  the 
simulation  independent  of  the  domain  of  applications. 
We  might  wish  to  simulate  a  power  plant  or  missile  - 
our  upper  most  level  should  not  reflect  what  partic¬ 
ular  application  we  are  using.  Objects  are  necessary 
to  control  or  manage  the  simulation.  By  controlling 
or  managing  the  simulation  we  mean  things  like  get¬ 
ting  user  input,  initialization,  starting  and  stopping 
the  simulation,  and  presenting  data.  The  objects  nec¬ 
essary  for  these  operations  are  identified  as  the  FXEC- 
UTIVE,  APPLICATION,  and  USERJNTERFACE. 
Each  is  briefly  described  below: 

«  The  EXECUTIVE  has  no  knowledge  of  what  type 
of  simulation  is  running,  it  just  sends  a  message  to 
APPLICATION  to  initialize  the  system  and  a  mes¬ 
sage  to  the  USERJNTERFACE  to  turn  over  control 
of  the  simulation  to  the  user. 
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the  real-world  probLm  space  into  the  objects  that  form 
the  software  solution. 

The  Missile.  It  includes  the  following  subsystem 
objects:  AIRFRAME,  AUTOPILOT,  RF-SEEKER, 
IR-SEEKER,  and  GUIDANCE.  The  AIRFRAME 
contains  further  subsystems  such  as  the  AERO  and 
•  THRUST.  The  missile  subsystems  serve  as  a  good  ex¬ 
ample  of  abstraction,  modularity,  low  coupling  and 
high  cohesion. 

The  MISSILE  object  sends  messages  to  establish 
the  missile's  physical  characteristics  (such  as  mass, 
drag,  thrust,  and  initial  phase  of  flight),  the  launch 
type,  number  of  targets,  number  of  stand  off  jammers 
(SOJs),  electronic  counter  measures  (ECM)  power, and 
geometric  initial  conditions  (such  as  ranges  and  head¬ 
ing  angle). 

The  AIRFRAME  models  the  missile’s  aerodynamic 
characteristics  and  thrust  characteristics,  ft  initializes 
the  propulsion  phase  and  various  physical  constants, 
computes  the  missile’s  coefficient  of  drag  and  angle-of- 
attack,  and  provides  the  thrust  force  and  propulsion 
phase. 

The  AUTOPILOT  accepts  commanded  accelera¬ 
tions  and  returns  achieved  accelerations  dependent  on 
the  body  responses  of  the  missile. 

The  function  of  GUIDANCE  is  to  guide  the  mis¬ 
sile  to  the  target.  Simply  stated,  given  missile  and 
target  position  and  velocity  information,  GUIDANCE 
determines  the  required  acceleration  commands  for  the 
missile  to  intercept  the  target. 

The  missile  uses  its  RF  (radar)  or  IR  (infrared) 
seeker  to  get  information  about  the  target.  At  longer 
ranges,  the  missile  simply  receives  the  RF  energy  re¬ 
flected  off  the  target  from  the  launch  aircraft’s  radar. 
At  medium  ranges,  the  missile’s  on-board  radar  acti¬ 
vates  to  provide  target  information.  At  short  ranges, 
the  missile  activates  its  IR  seeker  to  acquire  and  track 
the  target  in  the  terminal  phase  of  flight. 

The  Launcher.  The  LAUNCHER  object  represents 
the  aircraft  that  carries  and  launches  the  missile.  It 
provides  launch  aircraft  information  (such  as  velocity 
and  position,  and  certain  radar  characteristics  based 
on  the  launch  aircraft  type)  for  use  by  the  missile. 
Other  functions  include  providing  the  distance  from 
the  launch  aircraft  to  the  target  and  the  launch  air¬ 
craft’s  velocity  if  it  is  in  the  pursuit  guidance  mode. 

The  Target.  The  TARGETS  object  models  the  air¬ 
craft  that  the  missile  is  to  intercept.  The  Ada  package 
TARGETS  is  made  up  of  four  targets.  Two  of  these 
targets,  target  one  and  target  two,  are  treated  as  the 
primary  targets,  and  targets  three  and  four  are  treated 


as  stand  off  jammers  (SOJs).  The  major  task  of  TAR¬ 
GET  is  to  calculate  the  targets’  position,  velocity  and 
heading  angle  dependent  on  target  maneuver.  Appro¬ 
priate  conditions  arc  checked  resulting  in  the  setting 
of  flags  and  the  times  for  the  corresponding  target  ma¬ 
neuver.  Then  the  build-up  time  must  be  considered. 
The  build-up  time  is  the  time  from  the  initiation  of  the 
maneuver  until  the  desired  number  of  g’s  is  achieved. 
This  models  the  real  world  condition  that  commanded 
maneuvers  are  not  achieved  instantaneously.  The  rate 
of  change  of  the  target’s  heading  is  then  calculated 
along  with  the  number  of  g’s  the  target  is  experienc¬ 
ing.  The  current  target  heading  angle  is  then  com¬ 
pared  with  the  final  desired  turn  angle.  The  target 
velocity  vector  and  inach  are  then  computed.  Finally, 
the  second  target’s  position  is  computed  based  on  its 
geometric  relation  with  the  first  target. 

The  Support  Objects 

Modular  design  ami  information  hilling  allow  the  simu¬ 
lation  to  be  machine  independent.  Our  simulation  was 
developed  and  implemented  on  an  IBM  AT  compati¬ 
ble  machine.  However,  the  simulation  can  be  mod¬ 
ified  to  run  on  other  systems.  To  aid  this  process, 
all  the  machine  dependent  code  is  implemented  (hid¬ 
den)  in  the  SYSTEM-SPECIFIC  object.  Most  of  this 
code  is  associated  with  the  video  display.  By  rewrit¬ 
ing  SYSTEMJSPECIFIC  for  the  other  hardware  plat¬ 
forms,  and  keeping  the  original  message  names,  the 
porting  process  should  consist  simply  of  recompilation 
of  SYSTEM-SPECIFIC  and  a  link  of  the  simulation. 
Also  by  working  at  a  lower  system-specific  level  all 
screen  displays  are  output  in  the  most  efficient  manner 
providing  very  fast  screen  updates.  This  prevents  the 
user  from  perceiving  a  delay  as  the  screen  is  updated 
or  the  next  menu  is  displayed  (problems  experienced 
in  earlier  FORTRAN  simulations). 

Other  support  objects  include  (1)  INTEGRATION, 
which  performs  the  numerical  integration  of  the  MIS¬ 
SILE  and  TARGET  state  variables,  (2)  MATH,  which 
provides  external  messages  that  perform  all  the  ba¬ 
sic  mathematical  operations  required  by  the  simula¬ 
tion,  and  (3)  REAL-MATRIX,  which  is  the  generic 
object  MATRIX-AND-VECTOR  instantiated  for  the 
read  data  type,  and  provides  a  number  of  messages  for 
operations  on  matrices  and  vectors  because  many  of 
the  quantities  encountered  in  the  simulation,  such  ais 
forces,  are  best  expressed  in  terms  of  vectors  or  airrays. 

Object  Messages  and  Implementation 

The  Ada  with  clause  allows  a  package  (or  object)  to 
access  or  view  another  package’s  specification.  Pack¬ 
age  specifications  define  the  interface  to  the  package 
in  terms  of  data  structures,  function  calls  and  proce¬ 
dure  calls  available  to  the  users  of  the  package.  In  our 
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object  oriented  view,  package  specifications  define  the 
external  messages  that  an  object  can  respond  to  by 
eliciting  some  type  of  action  or  providing  the  sender 
with  information.  Internal  messages  are  the  functions 
and  procedures  that  are  in  the  body  and  not  in  the 
package  specification,  and  therefore  are  for  the  exclu¬ 
sive  use  of  that  object. 

A  detail  account  of  the  actual  FAS  code  ;uid  simu¬ 
lation  scenarios  can  be  found  in  a  report  by  Waite10. 

CONCLUSIONS 

We  have  explored  using  object  oriented  techniques  and 
software  engineering  principles  in  conjunction  with  the 
Ada  programming  language  to  develop  a  missile  flight 
simulation.  By  using  these  techniques  and  principles 
the  problem  space  is  accurately  mapped  into  software. 
This,  along  with  the  principles  of  abstraction,  infor¬ 
mation  hiding,  modularity,  loose  coupling,  and  strong 
i  nhesion  produced  a  simulation  that  is  easily  undcr- 
-tood,  modifiable,  efficient,  and  reliable. 

Although  undcrstandability  can  be  very  subjective, 
.ill  of  the  missile  analysts  who  reviewed  the  simula¬ 
tion  agreed  that  the  code  is  much  more  easily  under¬ 
stood  than  previous  FORTRAN  versions.  Modular¬ 
ity,  high  cohesion,  and  loose  coupling  permitted  the 
simulation  to  be  modified  in  easily.  Modules  were  de¬ 
signed  to  serve  a  single  purpose  and  to  make  use  of 
only  the  data  or  control  information  presented  by  the 
interfaces  of  other  modules.  All  the  interfaces  are  well 
defined  and  are  standard  for  that  particular  module.  A 
good  example  is  the  abstraction  of  the  missile  airframe 
subsystem.  By  being  modular  and  having  a  standard 
well  defined  interface,  this  subsystem  evolved  from  a 
program  stub  to  a  fairly  complex  model  with  mini¬ 
mal  programming  effort.  Also  by  having  a  standard 
well  defined  interface  between  objects  or  modules,  a 
library  of  different  models  can  be  built  to  explore  dif¬ 
ferent  missile  and  target  configurations.  The  simula¬ 
tion  is  simply  relinked  with  the  desired  module.  This 
allows  a  number  of  different  models  to  be  built  rel¬ 
atively  quickly.  These  models  then  can  be  used  for 
comparison  studies. 

Through  abstraction,  information  hidiug,  and  mod¬ 
ularity  a  very  efficient  user  interface  was  developed. 
The  simulation  has  also  proven  itself  to  be  highly  reli¬ 
able,  producing  consistent  results  that  agree  with  mis¬ 
sile  system  expert’s  predictions.  The  simulation  has 
also  proven  to  be  quite  robust,  surviving  the  most  mis¬ 
chievous  users  without  crashing. 
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Summaq: 

This  paper  describes  it«  design  and  development 
of  software  io  implement  Ada  Application  Program 
interfaces  to  X.400  ‘  message  handling  services.  This 
development  makes  it  possible  to  use  Ads  as  a  building 
block  of  future  mail  entitled  applications  that  send  and 
receive  electronic  messages  via  X.400  message  handling 
systems.  The  software  architecture  in  which  these  APIs 
|  arc  to  be  used  includes  (1)  the  application  program  dial 
j  creates,  sends,  receives,  and  processes  electronic 
!  messages,  and  (2)  the  message  handling  services  which 
!  arc  provided  with  a  standardized  API  compatible  with  C 
j  language  programming.  We  report  the  development 
process  and  discuss  the  long-range  impacts  and  lessons 
(earned  from  this  development  The  impacts  include  a 
significant  reuse  potential.  The  lessons  concent  die 
prospects  for  complete  Ada  developments  versus  API  use 
as  in  this  development 

lotroduvtiaa 

Ada  Application  Program  Interfaces  (APIs)  to 
X.400  services  provide  the  procedure  interfaces  and  dam 
definitions  to  enable  application  programs  to  send  and 
receive  X.400  electronic  messages.  The  development  of 
Ada  APIs  to  X.400  services  is  motivated  by  two 
important  mandates  for  US  Federal  Government 
computing  and  network  communications  -  Ada  language 
use  in  software  development,  and  use  of  International 
Standards  Organization  /  International  Telegraph  and 
Tclcphona  Consultative  Committee  (1SOAXTTT) 
protocols  for  the  exchange  of  data  between  computer 
systems.  This  latter  mandate  falls  under  (he  Government 
Open  System*  Interconnection  (OSD  Profile,  QOSIP. 
Another  motivation  for  Ada  APIs  to  network  services  it 
the  demand  for  distributed  applications.  Major  ones 
include  electronic  mail,  teleconferencing,  and  fUe 
transfers. 


X.400  services  are  used  for  exchange  of 
electronic  messages,  including  text  and  other  data  formats 
via  distributed  message  handling  systems.  These  services 
operate  much  like  postal  systems,  providing  writer-to- 
reader  services,  using  multiple  store- and  forward  points. 
Delivery  can  be  to  a  user  terminal,  to  a  user’s  file  store,  to 
a  facsimile  device,  or  even  as  hardcopy  through  a 
cooperating  physical  delivery  service. 

To  date.  Ada  has  not  had  widespread  use  in 
conjunction  with  ISOAXITT  protocols.  Where  US 
Government  policy  dictates  that  Ada  must  be  used  as  the 
development  language  and  that  ISOAXITT  protocols 
same  be  used,  per  the  GOMP.  there  is  a  serious 
deficiency.  One  aim  of  the  work  reported  here  is  to 
remedy  this  deficiency. 

The  X.400  APIs  described  here  are  designed  for 
developing  "user  agent*  (UA)  applications  that  interact 
with  the  X.400  message  handling  systems.  User  agents 
submit  and  retrieve  messages  during  sessions  with 
"message  transfer  agents*  (MTAs).  A  set  of  Ada  APIs 
wifl  be  especially  useful  u  agencies  that  develop  or 
acquire  user  agents  whom  development  muti  he  in  Ada 
for  reasons  of  mission  criticality,  required  trust,  etc. 

The  selected  Ada  APIs  are  the  projection  of  the 
X.400  API  Association's  (XAPlA't)  1990  C  language 
specifications  into  the  Ada  language.  Them  Ada  APIs 
MS  definitions  of  message  system  procedures  and  data 
objects  (U.,  messages  and  message  component  objects) 
isomorphic  to  those  of  the  X  APIA,  in  aider  to  facilitate 
easy  binding  to  software  products  that  conform  to  the 
XAPIA  tpet  tHcation.  Therefore,  this  woik  establishes  a 
major  basis  for  software  reuse,  enabling  users  to  develop 
message  agents  in  Ada,  that  can  interwork  with  COTS 
mamage  handling  components 
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Architecture 


The  X.400  protocol  standards  define  a  model  for 
electronic  moil,  as  ill  unrated  by  Figure  1.  The  model 
defines  User  Agents  (UAi)  and  Message  Transfer  Agents 
(MTAs).  UAs  assist  users  in  composing,  submitting,  and 
retrieving  mail,  and  they  allow  users  to  interact  with  the 
Message  Transfer  System  (MTS).  The  MTS  is  composed 
of  one  or  more  MTAs.  An  MTA  accepts  submitted 
messages  horn  UAs  for  delivery  to  other  UAs  and 
delivers  to  UAs  mail  received  from  other  MTAs. 


Figure  1. 

Ada  APIs  in  Message  Transfer  System 

The  Ada  APIs  provide  access  to  X.400  Message 
Transfer  System  (MTS)  services.  These  APIs  are 
provided  as  a  library  of  routines  that  are  used  by  a  user's 
application  code  (through  the  use  of  the  Ada  "with* 
directive).  This  combination  of  user's  application  code 
and  API  library  may  be  thought  of  as  an  X.400  User 
Agent  (UA).  where  the  user  code  calls  upon  API  services 
to  submit  and  retrieve  messages  from  the  MTS.  Figure  I 
also  depicts  the  relationship  between  the  Ada  APIs,  the 
-  UA  and  the  MTS  components. 

X.400  P2  is  the  protocol  that  prescribes  the 
format  of  messages  exchanged  between  two  UAs.  It 
includes  tha  message  originator,  recipients,  subject  text 
body.  etc.  X.400  PI  is  the  message  format  used  between 
two  MTAs;  PI  is  regarded  as  an  envelope  that  includes 
the  P2  messages. 

To  Interact  with  an  MTA  the  UA  must  first  open 
a  session.  A  session  is  a  set  of  message  submission  and 
retrieval  transactions  between  a  UA  and  an  MTA.  A  UA 
submits  a  mensngt  to  the  MTA  for  delivery  to  another  UA 


by  placing  the  message  on  a  submission  queue 
CSubmitQ"  in  Figure  1).  Once  the  message  has  been 
placed  on  this  queue,  the  message  is  under  the  control  at 
the  MTA  The  MTA  may  relay  the  message  to  a  remote 
MTA  or  may  deliver  the  message  to  a  local  UA  A  UA 
may  submit  any  number  of  messages  during  a  session. 

Messages  must  be  retrieved  from  the  MTA  by 
the  receiving  UA  When  a  message  is  received  by  the 
MTA,  the  MTA  places  the  message  on  a  retrieval  queue 
C'RelrieveQ").  The  receiving  UA  takes  responsibility  for 
a  message,  during  a  session,  by  removing  it  from  the 
retrieval  queue.  The  UA  may  also  interact  with  the 
retrieval  queue  by  querying  for  the  number  of  currently 
available  messages  or  by  issuing  a  "wait*  that  causes  the 
UA  to  suspend  its  processing  until  a  message  becomes 
available. 

Once  a  UA  has  finished  submitting  and 
retrieving  messages,  the  UA  may  dose  the  session  with 
the  MTA.  After  the  session  is  dosed,  the  UA  may  no 
longer  submit  or  retrieve  messages.  Messages  that  were 
in  the  submission  queue  when  the  session  was  dosed  are 
still  sent  by  the  MTA.  Messages  in  the  retrieval  queue 
and  delivery  notices  can  be  retrieved  when  a  new  session 
is  opened. 

To  summarize,  the  Ada  APIs  include  procedures 
for  the  following: 

*  open  a  session  with  the  message  handling  service; 

*  dose  the  session  with  the  message  service; 

-  submit  a  message  for  delivery; 

*  cancel  a  previously  submined  deferred  delivery 
message; 

-  start-retrieval:  remove  a  message  from  the  retrieval 
queue,  accessed  by  the  message  sequence  number 

*  finish-retrieval:  replace  the  message  in  the  retrieval 
queue,  or  discard  the  message; 

-  size:  obtain  the  number  of  messages  in  the  retrieval 
queue; 

*  wait  await  arrival  of  a  message  in  the  retrieval 
queue; 

Relation  lo.Siamiacb 

These  Ada  APIs  were  designed  to  meet  two 
goals:  (1)  to  make  X.400  services  accessible  to  Ada 
applications:  (2)  to  provide  specific  APIs  that  can  be 


cosily  bound  to  XAPtA-coniptiant  message  handling 
software.  By  adhering  to  XAPIA  standards  and  by  using 
XAPIA  massage  handling  software  (2),  these  APIs 
provide  access  to  X.400  protocol  services  (1). 

The  Ada  APIs  and  d;ita  objects  are  compatible 
with  commercial  message  handling  software  systems  that 
adhere  to  X.400  protocol  standards.  Therefore, 
applications  using  the  Ada  APIs  can  exchange  electronic 
messages  with  a  wide  range  of  other  applications,  via 
X.400. 

The  Ada  APIs  can  also  be  used  with  non* 
XAPIA-compliant  message  handling  software,  such  as  the 
University  College  London's  PP2.  In  this  case,  additional 
procedures  arc  needed  to  work  between  PFs  APIs  and  the 
standard  APIs.  Figure  2  illustrates  the  two  architectures 
for  the  un  of  the  Ada  APIs  to  X.400  services. 


Figure  2.  Two  Architectures  for  X.400  Use 


Ada  the  To  accomplish  this  development,  we 
relied  heavily  on  Ada's  support  for  object  oriented 
programming,  including  data  abstractions  and  packages. 
Wc  also  relied  on  Adi's  pragma  interface  for  access  to 
externally-provided  X.400  protocol  services  (e.g.,  from 
Messenger  400  or  from  PP).  Separate  Ada  packages 
contain  the  procedures  for  interacting  with  the  message 
handling  service,  for  defining  message  objects  and  for 
managing  message  objects. 

This  initial  use  of  Ada  to  support  message 
handling  objects  is  simplified  by  the  XAPlA's  very  clean 
separation  of  functions  and  data  objects.  The  XAPIA 
object  specifications  are  based  upon  an  inheritance 
hierarchy,  but  we  developed  specific  objects  only  for 


certain  classes  (messages,  addresses,  distribution  lists, 
etc.). 

Objects  Messages  are  the  top-level  objects  that 
are  passed  across  the  APIs.  Messages  contain  other 
objects  such  as  distribution  lists,  recipient  addresses, 
originator  addresses,  etc.  These  objects  in  turn  contain 
objects  for  the  address  components  (Country, 
Organization,  Surname,  etc.).  The  XAPIA  specifies  this 
level  of  object  definition;  moreover,  the  message  objects, 
so  far,  are  passive  and  contain  only  attributes,  not 
methods.  The  re-use  potential  of  the  object-oriented 
approach  will  be  realized  immediately  during  the 
development  of  mail-enabled  applications. 

Standard  routines  to  manage  objects  can  be  used 
for  both  general  and  special  objects  as  needed  by  mail 
enabled  applications.  For  example,  future  mail  enabled 
applications  will  likely  include  provisions  for  audio  and 
video  message  parts,  in  both  teleconferencing  and  non- 
real-time  use.  The  object  oriented  programming 
techniques  will  be  increasingly  useful  in  future  mail 
enabled  applications. 


project  constraints  delayed  acquisition  of  XAPIA 
compliant  message  handling  software.  Therefore,  the 
first  implementation  of  Ada  APIs  for  X.400  services  uses 
the  public  domain  PP  message  handling  software 
developed  by  the  University  College  London,  which  in 
turn  uses  protocol  services  from  ISODE  (public  domain  C 
language  implementations  of  ISO  protocols).  PP  and 
ISODE  are  now  supported  by  the  ISODE  Consortium. 

Ideally,  it  will  be  very  simple  to  bind  services 
provided  by  commercial  software  developed  in 
accordance  the  XAPIA  specifications,  to  the  Ada  API 
software,  via  a  small  set  of  interface  pragmas. 
Significantly,  our  use  of  PP,  whose  APIs  are  not  XAPIA* 
compliant,  also  shows  the  use  of  Ada  as  the  building 
block  between  APIs  based  on  the  XAPIA  specifications 
and  APIs  particular  to  PP. 

Tea  and  Demonstration  To  exercise  and  test  the 
APIs,  we  developed  several  simple  application  programs 
that  manage  objects  and  exchange  them  via  the  APIs. 
These  were  demonstrated  over  a  local  area  network.  An 
Ada  application  program  creates  and  manages  message 
objects,  opens  and  closes  sessions  with  a  message 
handling  service  provider,  submits  message  objects  to  it, 
retrieves  message  objects,  and  manages  the  contents  of 
the  message  retrieval  queue.  The  submitted  and  retrieved 
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messages  were  exchanged  with  another  Ada  application 
program,  via  PP  message  handling  services,  across  the 
local  area  network. 

Further  Experience 

The  XAPIA -based  approach  is  currently  proving 
its  rc-use  potential,  in  the  development  of  a  mail-enabled 
application  program  for  teleconferencing. 
Teleconferencing  is  a  much-needed  and  heavily  used 
military  command-center  application.  In  its  current 
version3,  it  is  not  based  on  Ada,  and  it  uses  a  command- 
line  interface.  Users  receive  messages  from  the  floor, 
through  a  chairman.  The  mail-enabled  teleconferencing 
uses  the  Ada  APIs  to  X.400  services  to  exchange 
messages  between  conference  participants,  and  it  interacts 
with  users  via  X  window  services. 

Most  teleconferencing  applications  rely  on  real¬ 
time  protocols.  However,  the  performance  of  prototype 
systems  using  PP  allowed  submitted  messages  to  be 
retrieved  within  about  1  second  by  recipients.  Therefore, 
X.400  services  were  chosen  because  they  can  provide  for 
the  other  primary  needs  of  a  teleconferencing  application, 
including  basic  message  delivery,  deliver  to  multiple 
recipients  (i.c.,  the  teleconference  participants),  delivery 
to  conference  records,  etc. 

We  developed  the  application  based  upon  the 
APIs  described  above,  according  to  the  model  on  the  left 
hand  side  of  Figure  2.  We  developed  bindings  as  shown 
in  tiiat  figure;  code  for  these  is  simple  and  short  In  other 
words,  we  were  able  to  reuse  the  core  work  of  the  initial 
development  but  did  not  reuse  the  mapping  procedures 
shown  in  Figure  2. 

We  used  vendor-provided  bindings  to  XView 
window  services  to  create  and  manage  window  objects. 
In  particular,  "button*  objects  cause  specified  functions  to 
be  executed  when  the  button  is  pressed.  For  the 
teleconferencing  application,  these  functions  based  on  the 
Ada  APIs  to  X.400  network  services  to  perform  message 
handling  services  in  response  to  user  actions.  For 
example,  the  "Send*  button  activates  a  procedure  that 
collects  text  from  a  text  window,  and  then  constructs  a 
message  to  the  teleconference  that  uses  this  text  as  the 
"Content",  and  finally  invokes  the  "send"  API. 

In  summary,  the  approach  of  using  Ada  APIs 
allowed  us  to  develop  an  Ada  application  that  makes  use 
of  up-to-date  systems  for  both  message  handling  and 
window  management 


Software  Engineering  Implications 

This  work  developed  software  resources 
intended  specifically  for  re-use,  with  a  very  high  leverage 
potential  This  potential  hat  been  confirmed  by  early 
experience  in  actual  re-use.  This  section  will  briefly 
discuss  additional  implications  based  on  the  development 
experience,  and  based  upon  projecting  re-use  in 
potentially  large  or  critical  applications. 

Development  Lessons 

Complexity  This  development  showed  utility  of 
development  based  upon  standards,  rather  than  more 
abstract  requirements.  The  literal  software  requirements 
were  quite  bounded  and  not  subject  to  change  during  the 
development  This  fact  constrained  the  growth  of 
sofrware  complexity. 

Using  automated  tods,  we  tracked  the  following 
complexity  metrics  during  the  development 

•  Cyclomatic  Complexity:  the  complexity  of  die 
program  execution  graph; 

-  Total  Operators  and  Unique  Operators  (Ada  language 
operators,  syntactic  elements,  etc.),  and 

-  Total  Operands  and  Unique  Operands, . 

Initial  measurements  were  made  on  the  Ada 
compiled  Program  Design  Language  (PDL)  version.  The 
complexity  grew  subsequently  as  various  interface 
methods  had  to  be  developed,  and  as  some  functions  were 
re-implemented  inside  more  than  one  package.  The 
Cyclomatic  Complexity  grew  from  75  to  450;  the  total 
number  of  operators  grew  from  8,000  to  10,000;  the  total 
number  of  operands  grew  from  500  to  6,000.  The  number 
of  lines  of  code  grew  from  600  to  2,600. 

The  particular  solutions  necessary  to  obtain  a 
workable  interface  and  functional  translation  between  the 
XAPIA  functions  and  those  offered  by  PP  were  the 
greatest  contributors  to  software  complexity. 

Fault  Dens;:/  We  found  that  fault  identification 
and  repair  in  the  development  process  worked  reasonably 
well  -  to  enable  the  software  to  pass  the  Formal 
Qualification  Tests.  The  density  of  faults  from  this  basis 
(identified  during  development  and  review,  and 
subsequently  corrected  prior  to  Formal  Qualification 
Tests)  was  about  10  faults  per  1,000  lines  of  code.  This  is 
less  than  might  be  expected  from  expert’s  experience4  - 
20-25  errors  per  1,000  lines  of  code. 
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Several  advantages  worked  together  against 
faults:  stable  requirements,  stable  design,  skilled, 

intelligent  development  staff,  and  a  test-and- 
demonstretion  covering  a  lot  of  execution  paths.  Had  any 
of  these  been  absent  from  the  development,  it  is  likely 
that  significantly  more  faults  would  be  experienced. 

Implications  for  Future  Use 

The  above-described  development  of  the 
teleconferencing  application  c;in  be  a  useful  model  for 
development  of  mission-critical  command  and  control 
implications  in  Ada  in  which  software  verification  is 
important.  The  APIs  allow  the  application  to  use  services 
of  software  developed  elscwiiere;  they  are  essentially 
input-output  services.  The  mission-critical  functions, 
such  as  message  validation,  release  subject  to 
authorizations,  authentication  of  senders,  etc.,  can  remain 
the  responsibility  of  the  Ada  application.  The  use  of  Ada 
APIs  can  significantly  reduce  the  effort  needed  to  verify 
the  application  software  as  needed  for  military  command 
and  control  applications. 

The  suggested  model  for  future  developments 
involves  stable  standards  for  the  API  to  furnished 
services,  such  os  message  transfer,  retrieval,  and  window 
management  The  stable  APIs  would  be  a  key  for  the 
widespread  use  of  the  services  furnished  via  utility 
software  and  would  free  developers  and  verifiers  to 
concentrate  on  functions  essential  to  the  application. 

Conchmons 

This  work  is  significant  because  it  is  one  of  the 
first  developments  for  Ada  use  of  the  International 
Standards  Organization's  Open  Systems  Interconnection 
(OSI)  communication  protocols.  It  is  now  a  Federal 
Government  mandate  to  acquire  OSI  protocols  in  new 
information  systems. 

This  work  demonstrated  the  use  of  two  different 
X.400  message  handling  software  systems  by  Ada 
.  application  programs,  plus  the  use  of  X-window  services. 
This  experience  shows  the  power  of  the  use  of  standard 
APIs  for  generic  services.  Develops  can  concentrate  on 
the  functions  essential  to  the  application  and  can  use 
generic  services  of  external  or  utility  software  by  means 
of  the  APIs. 

This  work  also  demonstrated  the  potential  of 
X.400  message  liandling  systems  to  be  used  not  only  for 
message  exchange,  but  for  near-real- time 


teleconferencing  as  well.  Despite  the  involvement  of  the  f 

disk  file  system,  message  transfers  could  be  accomplished 
in  approximately  one  second,  sufficient  for  ■ 

teleconferencing  use.  I 

Ada  served  as  the  primary  building  block 
throughout  the  developments  described  above:  I 

1.  it  was  the  basis  of  mapping  between  the  specified 

X  APIA  APIs  and  the  APIs  for  the  public  domain  PP  . 

message  handling  software;  I 

2.  it  was  the  basis  of  message  object  management 

utilities  to  be  used  with  the  message  object  > 

containment  hierarchy;  and  | 

3.  it  can  be  the  basis  of  message  processing  for  future 

mail  enabled  applications  themselves.  ■ 
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Abstract 

A  course  of  studies  toward  a  Masters  of 
Engineering,  Space  Operations  was  pursued  A  required 
prerequisite  for  this  degree  is  a  single  programming  class 
in  Ada.  This  prerequisite  was  completed  at  the 
University  of  Denver,  taking  the  graduate  level  Ada 
sequence.  Shortly  after  completing  the  Ada  curriculum, 
my  employer  arranged  for  me  to  attend  an  in-house 
Object  Oriented  Analysis  class  (using  the 
Shlaer/Mellor[l]  methodology).  These  classes,  along 
with  my  work  in  the  aerospace  industry,  emphasized  the 
importance  of  Ada.  A  personal  decision  was  made  to 
complete  all  astrodynamic  assignments  in  Ada  and 
develop  a  reusable  library  of  components.  The  programs 
were  developed  for  the  classes  in  Orbital  Mechanics, 
Launch  &  Re-entry,  and  Astrodynamics.  Although  Ada 
is  a  required  prerequisite,  I  believe  that  I  was  the  only 
student  out  of  the  30  or  so  students  in  my  classes  using 
Ada  for  the  assignments.  Other  students  used  C, 
FORTRAN,  and  Pascal.  While  new  to  Ada,  I  was  able  to 
easily  keep  up  with  my  colleagues,  demonstrating  that 
Ada  and  its  various  unique  features  are  not  difficult  to 
learn,  nor  the  cause  of  schedule  delays.  This  experience 
provides  some  insight  into  problems  existing  in  the  Ada 
community.  The  case  study  serves  as  a  starting  point  for 
others  considering  the  use  of  Ada  in  their  educational 
pursuit,  as  viewed  by  an  engineering  student  outside  of 
the  computer  science  discipline.  It  can  be  used  for 
discussions  on  the  advanced  topics  of  Ada,  i.e.,  how  to 
implement  a  project,  good  and  bad  methodologies, 
limitations,  and  allowing  students  to  learn  from  other’s 
attempts. 

Education 

For  a  large  corporation  to  bid  on  seme 
government  contracts  which  require  the  use  of  Ada,  the 
company  has  to  identify  its  resources  including  the 
number  of  Ada  programmers.  The  accepted  definition  of 
a  trained  Ada  programmer  is  60  hours  of  classroom 


training  and  60  hours  of  hands  on  experience.  This 
provides  a  very  minimal  education  of  Ada.  Completion 
of  this  type  of  training  provides  the  student  with  the  basic 
understanding  of  the  syntax  and  little  more.  I  was 
fortunate  to  receive  my  Ada  education  in  a  fast  paced 
environment  of  graduate  computer  science  students.  We 
approached  the  subjects  of  object  philosophy,  generics, 
.d  tasking  in  a  detailed  manner  as  implemented  in  Ada. 
The  curriculum  for  this  sequence  of  classes  included  the 
dining  philosopher  problem  using  a  state  machine  and 
arm  of  tasvs  for  each  of  the  objects.  It  became  an  eye 
opene-  r,  to  the  amount  of  processing  that  can  be 
accomplished  with  so  little  code. 

The  most  common  student  in  an  Ada  class  is  an 
engineer  with  experience  usually  in  FORTRAN,  whose 
employer  is  considering  the  use  of  Ada.  His/her 
engineering  discipline  may  vary  but  for  the  most  part  it  is 
applied  outside  of  the  computer  science  field.  Typical 
disciplines  are  controls,  navigation,  guidance,  or 
structures.  These  engineers  leave  their  work  assignments 
for  a  few  weeks  to  receive  Ada  training.  When  they 
return  to  ‘heir  jobs,  and  only  when  required,  they  begin 
to  write  in  Adatran,  Ada  that  looks  exactly  like  the 
FORTRAN  that  they  were  previously  using.  The  code 
uses  "common  blocks",  no  generics  nor  tasks,  and  is 
usually  contained  in  one  package. 

The  fault  does  not  lie  with  these  engineers.  The 
system  only  provided  time  for  learning  a  new  syntax,  not 
a  new  software  engineering  methodology.  One  of  the 
philosophical  goals  of  Ada  is  to  improve  the  overall 
education  in  software  engineering.  This  case  study 
attempts  to  utilize  some  software  engineering  training  to 
create  an  Ada  software  model  based  on  more  modem 
techniques  and  methodologies. 

Data  is  Lacking 

Many  of  the  best  features  in  Ada  such  as  generics  are 
underutilized  due  to  the  fact  that  standards  and  literature 
describing  how  to  create  a  good  generic  are  lacking. 
While  this  case  study  will  not  establish  a  standard,  it  may 
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contribute  to  the  discussions  and  interests  of  other 
students  to  review,  criticize  and  improve  on  the  models 
developed  in  this  case  study. 

The  basic  concepts  of  object  oriented 
programming  seem  so  abstract  when  attempting  to  tackle 
a  problem  in  astrodynamics,  but  alter  many  revisions,  it 
ends  up  being  veiy  logical. 

A  Good  Starting  Point 

This  case  study  provides  a  complete  working 
model  that  can  be  expanded,  modified,  corrected, 
improved,  or  discarded  completely.  However,  it  can 
provide  that  start  necessaiy  for  discussion.  In  addition,  it 
may  provide  some  reusable  components  that  an 
engineering  student  may  And  helpful  in  pursuit  of  their 
education.  It  should  provide  a  challenge  to  educators  and 
students  to  solve  the  problem  in  a  better  way. 


Not  everything  in  this  world  is  black  and  white, 
nor  should  the  standards  on  the  best  way  to  code. 
Software  engineering,  and  engineering  in  general  is  a 
process  or  method  used  to  solve  a  problem.  There  may 
exist  an  infinite  number  of  possible  solutions,  but  the 
engineer  must  decide  on  one  solution  which  is  a  cost 
effective,  safe,  and  practical  solution.  This  usually 
results  in  a  compromise.  One  piece  of  code  cannot 
necessarily  be  the  do-it-all  for  every  application.  Real 
time  simulation  engineers  have  different  requirements 
than  that  of  simulation  engineers  needing  to  work  with 
very  high  fidelity  models.  The  engineer  is  now  tasked  to 
not  only  solve  the  problem  for  today,  but  also  for  the 
future.  To  develop  a  reusable  component,  it  must  be 
practical,  efficient  and  maintainable. 

Practicality  means  case  of  use.  A  complex 
generic  routine  using  access  types  of  records  just  to  add 
two  numbers  would  overwhelm  anyone,  even  if  it  could 
be  used  by  anyone  for  anything  needed  to  be  added.  The 
component  must  first  make  sense.  To  make  every  object 
a  limited  private  to  enforce  the  highest  levels  of 
encapsulation  and  hiding  may  not  provide  a  practical 
solution.  Ease  of  use  must  be  considered  for  the  current 
and  future  users.  Most  engineers  prefer  to  use 
assignment  statements  for  their  operations  so  that  the 
code  looks  like  the  equation  in  the  text  book.  For 
example,  if  the  following  equation  is  desired: 


f  =  — 

M  r U 


r  •vjv 


The  Ada  would  look  like  the  code  fragment  in  figure  1. 

r  :>  NORM  (State_Date.Pe*Hk>n); 
v  :■  NORM  (State JfctaVdoctty); 
g  v*c  :*  (1.0/MU) 

•  ({(v**2  -  MU/r) » State_DaU.Po»ition) 

-((Stato_Data.  Po*tion*State_Data.  Velocity) 
•State.Date.Vetodty)) ; 

where  .Position  and  .Velocity  are  arrays,  the 
is  a  dot  product  between  vectors,  and  a 
scalar  ♦  vector  multiply  as  overloaded.  The 
is  a  subtraction  between  two  vectors,  resulting 
in  a  vector. 

“  Figure  1,  Sample  Ada  Equation 

Limited  privates,  since  they  exclude  assignment 
statements,  do  not  permit  functions  as  operations  on  their 
objects.  The  above  example  using  limited  private  types 
would  have  an  unnatural  look  to  the  engineer  forcing  the 
use  of  COPY  or  ASSIGN  procedures.  However,  limited 
privates  do  have  their  place  and  should  be  used  when 
practical. 

Practicality  also  gives  the  engineer  the  choice 
when  to  make  something  very  "object  oriented"  or 
function  oriented.  Examples  are  the 

Generic_Elementaiy_Functions(2]  and  the 

GenericJLinear  Functions.  The  linear  functions  for 
example  could  have  provided  very  encapsulated  private 
vector  and  matrix  types.  An  engineer  would  have  gone 
crazy  using  the  package  functions  set  and  get  to  obtain 
individual  values  from  the  elements  of  the  vector  or 
matrix.  Anticipate  the  common  usage  of  the  component, 
or  it  will  be  re-written  or  unused. 

Efficiency  led  to  the  creation  of  many  similar 
functions  encapsulated  into  a  single  package.  A  good 
example  of  this  is  the  gravity  model  package,  "Gravity." 
This  generic  package  contains  many  different  models  of 
the  earth's  gravitational  acceleration.  It  is  expected  that 
only  one  of  the  models  would  eventually  be  utilized  after 
instantiation.  This  provides  the  user  a  selection  of 
fidelity  verses  speed  with  little  overhead.  It  would  have 
been  possible  (and  I  plan  to  add  one  in  the  near  future)  to 
write  a  routine  that  would  have  a  parameter  selection  as 
to  the  order  of  the  gravity  model.  This,  however,  would 
have  caused  inefficiencies  for  the  real  time  user  and 
minimized  the  reuse. 

Maintainability  is  the  most  difficult  aspect.  The 
code  must  be  written  in  a  familiar  form  such  as  the 
equivalent  to  equations  in  the  text  books.  Documentation 
must  be  maintained  along  with  the  code.  Object  oriented 
techniques  did  help  provide  an  expandable  set  of 
packages  from  which  to  work.  It  also  made  for  the  most 
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difficult  decisions,  when  attempting  to  implement  a 
different  interface/method  for  a  complete  generic 
package.  For  example,  it  is  not  necessary  to  declare  a 
matrix  type  just  to  instantiate  the  linear  functions 
package  if  all  that  is  needed  was  to  manipulate  vectors. 
Changing  the  package  to  a  nested  implementation  where 
the  matrix  was  a  generic  package  within  the  vector 
packaged  caused  more  changes  that  I  had  planned. 

Unfortunately  (or  for  those  in  the  business 
fortunately),  maintenance  is  a  never  ending  task,  and 
attempting  to  improve  the  case  study  by  changing  the 
interface/implementation  to  a  different  scheme  is 
difficult.  There  is  more  than  one  correct  way  to 
implement  this  code,  and  perhaps  over  time  the  optimal 
will  be  discovered. 

Validated  Compilers 

It  is  interesting  to  observe  the  types  of  bugs  that 
exist  in  some  validated  compilers.  I  am  convinced  that 
the  validation  suite  was  developed  by  Atatran  coders. 
Mosv  all  of  the  bugs  in  the  compiler  that  I  have 
discovered  were  from  the  generic  implementation  of 
"objects".  These  errors  were  not  exercised  in  the 
validation  suite.  Some  of  the  choices  made  during  the 
implementation  of  this  case  study  were  due  to  work¬ 
arounds  in  the  compiler,  not  due  to  good  engineering 
practices. 

Examples  of  compiler  bugs  are  worthy  of 
review.  I  was  able  to  instantiate  a  generic  package  to 
make  a  function  visible.  That  function  would  work 
normally  in  the  routine  in  which  it  was  instantiated,  but  I 
was  unable  to  pass  that  function  as  an  generic  actual 
parameter  to  another  generic  package  although  functions 
not  declared  in  instantiated  packages  did  pass  as 
parameters  correctly.  This  initially  presented  me  from 
instantiating  a  linear  function  package  then  passing  these 
functions  as  parameters  to  other  generic  functions. 
Another  example  was  the  inability  to  utilize  enumeration 
types  passed  as  generic  actual  parameters.  I  could  not 
even  instantiate  Text_IO.Enumeration_IO  using 
enumeration  types  due  to  these  generic  problems.  In 
some  cases  these  enumeration  problems  passed  through 
the  compiler  and  prevented  linking  or  just  created  code 
errors.  Another  example  was  the  inability  to  pass  an 
array  type  which  was  declared  in  a  generic  package  as  a 
formal  parameter  into  another  generic  package. 

I  felt  that  I  was  the  only  person  using 
enumeration  types  and  generics.  However,  I  was 
extremely  pleased  by  the  compiler  vendor  fixing  the 
problems  and  sending  me  a  beta  copy  to  continue  work. 
This  is  the  type  of  support  that  would  be  expected  on  a 


big  budget  industrial  project,  but  very  happy  to  say  it  was 
also  provided  to  an  individual  trying  to  complete  a 
homework  assignment. 

Other  difficulties  are  cost  and  capability  of 
compilers  on  personal  computers.  This  code  is  not  that 
complex,  however,  most  of  the  "educational"  compilers 
cannot  compile  this  code  due  to  "out  of  memory"  type 
errors.  More  money  had  to  be  spent  to  purchase  an 
upgraded  compiler  to  be  able  to  even  compile  this  code. 
This  code  will  compile  and  work  well  with  the  R&R 
Software  386-to-DOS  Janus  Professional  Compiler. 

The  style  of  code  written  in  the  Ada  classroom 
environment  is  basically  syntax  oriented.  Code  written 
on  a  project  (even  if  it  is  just  homework)  in  an  object 
oriented  fashion  is  much  different.  Deciding  the  best 
methodology  for  gluing  together  generic  packages 
requires  the  engineering  work,  and  not  much  guidance 
exists  in  the  literature.  At  least  for  the  near  future,  good 
engineers  are  required  in  the  code  generation  process. 

The  Code 

Over  60  pages  of  code  resulted  from  this  effort 
Each  package  was  developed  to  be  stand-alone  and 
reusable.  I  maintain  a  three  ring  binder  for  the 
documentation  each  divider  containing  one  package  with 
the  requirements,  design,  code,  notes,  copies  of  pages 
from  text  books  and  other  references,  test  programs  and 
results.  The  packages  that  tie  the  code  together  are  the 
templates  which  use  the  package  Astro_States  as  the 
primary  package.  Once  properly  instantiated,  the 
engineer  can  write  application  code  similar  to  a  MathCad 
or  MatLab  program  utilizing  functions  specific  to 
astrodynamics.  The  advantage  is  the  capability  to 
compile  this  code  so  that  it  can  run  real  time  or  faster. 

This  code  is  centered  around  a  package  called 
Astro_States.  This  package  defines  three  objects,  which 
contain  the  state  information  (position  and  velocity)  in 
three  different  frames  of  reference:  Classical  Keplerian 
Elements,  Earth  Centered  Inertial  (fixed  frame)  and 
Flight  Path  Coordinates  (rotating  frame).  Figure  2  is  two 
code  fragments  from  Astro_States  including  the  private 
part  describing  the  states. 

These  private  types  have  member  functions  to 
initialize  the  states,  convert  between  the  states  and  also 
get  data  from  the  states.  Two  other  functions  are  time  of 
flight  between  two  states,  and  a  ballistic  propagation 
function  given  a  time.  The  package  also  develops  the 
derivatives  of  the  states  for  use  in  an  integrator. 
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Package  ASTRO.STATES  is 

typo  Index  Is  ( X ,  Y ,  Z ,  -  ECI  Axes 

Roll ,  Pitch ,  Yaw ,  -  Body  Axes 

Vel ,  Azm ,  FPA ,  Long ,  Lat ,  Rad ,  Mass ,  -  FPC 
a ,  e ,  i ,  RAAN ,  Arg_P« ,  Tr_Anom ,  -  CKE 

-Generic 


private 

subtype  BCIJndex  is  Index  range  X ..  Z ; 
subtype  CKEJndex  is  Index  range  a ..  Tr_Anom ; 
subtype  FPCJndex  is  Index  range  Vel ..  Mass  ; 
subtype  Bodyjndex  Is  Index  range  Roll ..  Yaw ; 

subtype  Positionjype  is  Vector  ( BCIJndex ) ; 
subtype  Ve!ocity_Type  is  Vector  ( BCIJndex ) ; 
subtype  CKE_Data_Type  is  Vector  ( CKEJndex ) ; 
subtype  FPC JJataJTypo  is  Vector  ( FPCJndex ) ; 
subtype  Attitude_Type  is  Vector  ( Bodyjndex ) ; 
subtype  Rate_Type  is  Vector  ( Bodyjndex ) ; 

type  BCI_3D  is  record 
Position :  Position_Type ; 

Velocity :  Ve!ocity_Type ; 

Time  :  Real ; 
end  record ; 

type  CKE_3D  is  record 
CKE_Data_Set :  CKE  J)ata_Type ; 

Time  :  Real ; 

end  record; 

type  FPC_3D  is  record 
FPC_Data_Set :  FPC_Data_Type ; 

GHA  :  Real ; 

GMT  :  Real ; 

end  record ; 


end  states; 

end  ASTRO_STATES ;  _ 

Figure  2,  Code  Fragment  from  Astro_States 

The  integrator  package  currently  contains  three 
integrators,  an  Euler,  RK4,  and  a  6th  order 
predictor/corrector  integrator,  but  will  in  the  future 
contain  others.  The  derivative  function  is  passea  as  a 


generic  parameter  to  the  integrator  which  in  turn  is  used 
as  a  generic  function  back  in  the  Astro_States. propagate 
package  to  permit  integration  of  the  state  over  time.  The 
object  being  integrated  is  private,  allowing  the 
integrators  to  be  used  on  many  different  types. 
Additional  generic  parameters  include  specific  operations 
on  the  type  being  integrated  so  that  the  functions  can 
implement  the  processing.  Additional  features  include 
an  optional  adaptable  step  size  on  the  RK4  integrator  to 
minimize  processing  errors.  Figure  3  is  an  example  of 
one  fragment  of  the  package  specification. 


package  Integrators  is 
Integration.Error :  exception ; 


generic 

type  Variables  is  private ; 

type  Real  is  digits  o ; 

with  function  DerivfX  :  in  Variables; 

Y :  in  Real )  return  Variables  is  o ; 
with  function  ( X ,  Y :  in  Variables )  return  Variables  is 

o; 

with  function  "*"  ( X :  in  Real ;  Y :  In  Variables )  return 
Variables  is  o; 

package  Euler  is 
procedure  lntegrate_Euler 
(Y_Start  :  in  Variables; 

X_Start  :  in  Real; 

X_End  :  in  out  Real; 

Step.Size :  in  out  Real; 

Y_E.id  :  out  Variables); 

end  Euler; 


Figure  3,  Code  Fragment  from  Integrators 

Functions  that  need  to  be  passed  as  generic 
parameters  to  the  Astro_States.Derivative  package  are 
Lift,  Drag,  Tlu-ust,  and  Gravity.  The  Lilt,  Drag,  and 
Thrust  functions  have  typically  been  coded  in  one 
package  called  Vehicle. 

The  Gravity  package  provides  for  many  gravity 
models  including  a  J2  and  J4  model.  These  functions, 
given  a  position  vector,  provide  an  acceleration  vector 
describing  the  magnitude  and  direction  of  "down".  Since 
the  earth  is  not  perfectly  spherical  nor  is  the  density 
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uniform,  "down"  changes  from  here  to  there.  This 
results  in  changes  in  the  orbits  of  satellites.  This  package 
allows  the  user  to  determine  the  accuracy,  or  order,  of  the 
model.  The  higher  the  order  of  the  model,  the  more 
processing  time  is  required.  In  addition  to  the  existing 
models  work  is  currently  underway  to  develop  a  tesseral 
and  sectorial  model  (coefficients  are  available  to  about  a 
SO  by  50  model)  as  a  task  to  run  in  parallel  with  the 
simulation.  The  high  frequency  integrator  would  use  a 
J2  or  J4  calculation  plus  a  delta  being  the  difference 
between  the  JX  model  and  the  S0x50  model  until  the  task 
completes,  at  which  time  the  delta  is  updated. 

A  linear  (unction  package  was  written  as  a 
generic  with  unconstrained  array  sizes  and  enumeration 
types  for  the  index.  This  permits  access  to 
State_Data.Position(X)  in  the  ECI  frame  for  readability. 
This  makes  the  linear  function  package  somewhat  more 
complex  since,  the  matrices  and  vectors  don't  have  simple 
ranges  with  which  to  work.  Also  the  package 
Generic_Linear_Functions  has  a  nested  arrangement  so 
that  the  inner  package  is: 

Generic_Linear_Functions.Generic_Vector_Functions. 
Generic_Matri.\_Functions.  Initially  it  was  coded  such 
that  a  matrix  type  had  to  exist  in  order  to  use  just  vector 
functions.  The  nesting  proved  to  be  an  adequate  simple 
solution  so  that  matrices  did  not  have  to  exist  for  vector 
only  processing.  Other  evolution  changes  were  the 
philosophy  to  treat  the  linear  functions  similar  to 
transcendental  functions  as  intrinsic,  or  force  the  user  to 
a  very  strict  object  oriented  philosophy,  requiring  the 
passing  of  many  functions  as  parameters  to  each  package. 
The  feature  of  overloading  tended  to  influence  me  to 
toward  an  intrinsic  implementation,  but  maintenance  and 
flexibility  won  out  for  an  object  based  package.  The 
functions  are  passed  as  parameters  in  generics  rather 
than  the  package  being  "withed"  in  the  implementation. 
Plans  exist  to  continue  the  nested  chain  and  add 
Generic_Quatemion_Functions  within  the 

. Generic_Matrix_F unctions  package.  A  code  fragment  is 
shown  in  figure  4. 


with  UNEAR_FUNCTI0NS_EXCEPT10NS; 
package  Generic JJnear_Fune3ons  is 

-  Package  Vectors  provides  functions  for  the  object 
■Vector- 

generic 

type  Index  is  ( o ) ; 
type  Real  is  digits  o ; 

type  Vector  is  array  ( index  range  o )  of  Real ; 


wfthfunctionsqrt(X:  in  Real) return  Real  Is o; 
with  function  arccos  (X :  in  Real )  return  Real  is  o; 

package  GENERIC_VECTOR_FUNCTiONS  is 

function  V  (Ve  :  in  Vector)  return  Vector; 
function  "•"  (Vec  d :  in  Vector)  return  Vector; 
function  ( Vec  J ,  Vee_2 :  in  Vector )  return  Vector ; 

function  ( Vec_1 ,  Vec_2 :  in  Vector )  return  Vector ; 
function  ( Scalar :  in  Real ;  Vec_1 :  ir<  Vector )  return 
Vector; 

function  ( Vec_1 :  in  Vector ;  Scalar :  in  Real )  return 
Vector; 

function  T  ( Vec_1 :  in  Vector ;  Scalar :  in  Real )  return 
Vector; 

function  ***  ( Vec_1 ,  Vec_2 :  in  Vector )  return  Real ; 
function  Dot  ( Vcc_1 ,  Vec_2 :  in  Vector )  return  Real 
renames  ; 

function  "**"  ( Vec_1 ,  Vee_2 :  In  Vector )  return  Vector ; 
function  Cross  ( Vec_1 ,  Vec.  2 :  in  Vector )  return  Vector 
renames  "**" ; 

function  Angle  ( Vec  J  ,  Vee_2 :  in  Vector )  return  Real ; 
function  Norm  ( Vec_1 :  in  Vector )  return  Real ; 
function  Unit  ( Vec_1 :  in  Vector )  return  Vector ; 
procedure  Put  ( Vec_1 :  in  Vector ) ; 

generic 

type  Matrix  is  array  ( Index  range  o ,  Index  range  o )  of 
Real; 

package  GENERIC_MATRIX_FUNCT10NS  is 

function  (Mat_1 :  in  Matrix)  return  Matrix; 
function  (Mat_1 :  in  Matrix)  return  f’atrix; 
function  "♦"  ( Mat_1 ,  Mat_2 :  in  Matrix )  return  Matrix ; 
function  "•"  ( Mat_1 ,  Mat_2 :  in  Matrix )  return  Matrix ; 
function  ( Scalar :  in  Real ;  Mat_1 :  in  Matrix )  return 
Matrix; 

function  **"  ( Mat_1 :  in  Matrix ;  Scalar :  in  Real )  return 
Matrix; 

funr  don  V  ( Mat_1 :  in  Matrix ;  Scalar :  In  Real )  return 
Matrix ; 

function  ( Mat_1 :  in  Matrix ; 

Vec  1 :  in  Vector )  return  Vector ; 
function  "*•  ( Ma'J :  in  Matrix; 

Mat_2 ;  in  Matrix )  return  Matrix ; 
function  Invert  ( Mat _1 :  in  Matrix )  return  Matrix ; 
function  Transpose  ( Mat_1 :  in  Matrix )  return  Matrix ; 
procedure  Put  ( Mat_1 :  In  Matrix ) ; 


Figure  4,  Code  fragment  from 
Generic_Line*r_Functionj  Specification 
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To  work  one  of  the  boundary  condition  problems 
for  reentry,  a  quartic  root  function  was  required.  This 
resulted  in  a  package  called  Real  .Roots  that  has  closed 
form  solutions  to  the  Quadratic,  Cubic  and  Quartic 
functions. 

The  vehicle  model  required  atmosphe  .  data  to 
calculate  drag,  lift  and  thrust.  A  package  Atmosphere 
was  developed  to  provide  functions  for  density,  altitude, 
radius  of  the  earth  at  given  latitudes,  mach  number  and 
other  atmospheric  data. 

The  atmosphere  model  required  table  lookup,  so 
a  package  Tables  was  developed  to  do  linear 
interpolation  on  10  and  2D  tables.  Possible  future 
additions  to  this  would  be  more  exotic  interpolation 
techniques  and  a  binary  search,  verses  the  linear  search 
currently  implemented. 

The  last  two  miscellaneous  packages  are 
Astro  Constants  and  Transformations. 

Templates  were  developed  for  the  final 
applications,  see  figure  1.  The  templates  instantiate  the 
generics  in  the  proper  order,  allowing  the  user  code  to  be 
written  with  all  of  the  available  objects  and  rn.mber 
functions.  One  template  instantiates  the  high  fidelity 
models  and  the  other  instantiates  real  time  models.  This 
permits  the  final  application  to  be  up  and  running 
quickly.  Final  adjustments  can  then  be  made  in  the 
model  selection  for  the  application. 
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Figures,  Template 


This  code  is  available  to  students  and  educators 
by  sending  a  3.5  or  S.25  floppy  and  a  SASE  to: 

Roger  Kovacs 
2003  S.  Evanston  Ct 
Aurora,  CO  80014 

The  code  is  provided  for  non-profit  use,  and  feedback  is 
greatly  encouraged. 


Lessons  Learned 

Determining  the  object  is  the  most  difficult  part. 
Defining  the  object  once  identified  is  simple.  This  must 
be  an  iterative  process  and  should  not  be  constrained  by 
automated  tools  and  processes.  A  simple  change  to  the 
main  object  may  and  in  many  cases  cause  one  to  discard 
most  all  of  the  previous  work.  This  freedom  must  be 
preserved  during  the  first  part  of  a  life  cycle. 

The  structure  of  the  program  dictates  the 
interfaces  and  member  functions  required.  This  structure 
has  to  conform  to  the  limitations  of  the  Ada  syntax  and 
compiler  bugs.  Ada  9X  will  provide  more  freedom.  This 
too  is  an  iterative  and  a  learning  process.  Decisions 
made  include  package  structure,  (object  and  functional). 

Do-all  functions  may  be  reusable  but  in  the  end 
may  never  be  reused.  Careful  attention  must  be  paid  to 
all  aspects  of  reuse.  Engineering  is  an  art  and  science 
which  develops  a  solution  to  a  problem.  The  engineer, 
given  guidelines,  must  have  the  freedom  to  select  the  best 
solution.  Templates  provide  the  user  a  better  starting 
point  for  the  reuse  of  the  existing  code  then  just 
comments.  It  m ay  not  be  too  apnarent  to  a  future  how  to 
glue  together  the  appropriate  packages.  Modifications 
after  it  is  functional  are  much  easier  than  figuring  out 
how  to  start  from  scratch.  Reuse  is  the  key,  a  template  is 
good  reuse  when  the  general  application  doesn't  change 
much. 

Embedded  test  functions  or  separate  test 
packages  provide  a  simple  way  to  revalidate  changes. 
Most  compilers  have  appropriate  switches  to  eliminate 
code  that  does  not  link  in.  This  then  causes  no  additional 
overhead  to  the  end  user  and  can  provide  vital 
information  on  the  precision  and  correctness  of  the 
package  as  executed  on  various  platforms. 

Conclusion 

Ada  is  an  excellent  language  for  the 
development  of  reusable  packages.  The  extra  overhead 
required  to  use  Ada  over  other  languages  was  not 
noticeable.  I  was  able  to  keep  up  or  ahead  of  my 
colleagues  in  all  of  my  classes  using  more  of  the 
traditional  languages  doing  the  exact  same  assignments. 
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Future 


The  maturity  of  the  compilers  is  improving,  but  many  of 
the  other  languages  have  an  edge.  The  rejection  of  Ada 
as  the  language  of  choice  for  a  particular  project  is  more 
of  an  attitude  and  training  issue.  Quality  of  Ada  code  is 
an  experience  issue  and  coding  techniques  will  improve 
over  time.  Many  of  the  individuals  coding  today  in 
industry  are  engineers  of  disciplines  other  than  software 
or  computer  science.  It  may  be  simple  to  train  them  to 
learn  Ada  syntax,  but  the  larger  issue  of  writing  reusable, 
robust,  easily  maintained,  testable,  efficient  code  will  be 
difficult.  This  takes  Ada  (  and  software  engineering  life 
cycle)  experience  which  takes  time.  1  hope  to  develop 
over  time  a  balanced  blend  of  two  engineering 
disciplines.  Aerospace  and  Software,  and  to  be  able  to 
apply  software  discipline  to  aerospace  engineering. 

It  was  difficult  to  find  literature  in  libraries  to 
aid  the  development  of  good  generic  packages,  when  and 
where  to  use  private  and  limited  private  types  and 
examples  or  case  studies  somewhat  larger  than  a  few 
lines  of  code.  Once  a  standard  methodology  is  developed 
for  aiding  in  these  decisions,  Ada  will  stand  out  alone  in 
the  reusable  software  market. 

This  assignment  provided  me  with  lessons 
learned  that  is  documented  in  this  case  study. 
Engineering  is  a  decision  making  process  and  many  of 
these  decisions  were  difficult.  More  experience  will  aid 
in  the  maturity  of  the  code  generated.  I  recognize  that 
this  experience  only  touches  a  very  small  part  of  a 
software  life  cycle.  It  will  take  more  time  to  grow  and 
learn  through  experience  the  many  techniques  and 
methods  that  work  and  don't  work.  I  will  have  to  see 
which  modules  are  really  reused,  and  which  ones  are 
continually  rewritten,  and  for  what  reasons. 


I  envision  that  in  the  future,  software  can  be 
developed  with  a  graphics  interface  similar  to  current 
design  tools  which  will  use  these  and  other  reusable 
components,  and  allow  the  user  to  graphically  connect 
the  generic  parameters.  When  the  user  has  assembled 
the  reusable  components,  target  code  will  be  generated, 
and  Ada  will  be  produced  for  documentation  or  transfer 
to  a  different  target  computer.  Software  engineers  will 
only  be  required  for  developing  new  reusable  components 
(as  well  as  new  and  better  tools).  Just  as  robotics 
replaced  many  blue  collar  workers,  I  see  computers 
replacing  many  white  collar  workers.  I  desire  to  be  part 
of  the  developing  future,  not  standing  back  watching  it 
goby. 


Do  it  better,  and  let  me  know  how!  I  will 
provide  copies  of  the  code  into  the  public  domain  for 
non-profit  educational  use.  After  graduation, 
configuration  control  and  maintenance  will  be  provided 
for  some  time.  (Unfortunately,  it  would  be  an 
overwhelming  task  to  provide  notices  of  error  reports  to 
all  the  users,  so  just  write  often.)  The  evolution  of  this 
code  should  provide  a  much  better  case  study  than  the 
initial  release.  Let's  see  what  we  can  all  do  in  a  year. 


[1]  Shlaer,  S  and  Mellor,  S.,  OBJECT  LIFECYCLES. 
Modeling  the  World  in  States.  Yourdon  Press,  1992 

[2]  Generic_Elementaiy_Functions  as  proposed  by  the 
SIGAda  NumWG  in  1990. 
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Abstract 

Modern  software  management  and  quality 
assurance  necessitates  development  of 
unique  solutions  to  increasing  complexities. 
One  such  solution  is  the  concept  of  repre¬ 
senting  software  applications  in  hierarchal 
structures  such  as  file  list.  The  benefits  of 
the  file  list  are  listed  in  detail. 

Introduction 

Los  Alamos  National  Laboratory  Technical 
Software  Management  Group  employs  in¬ 
novative  approaches  to  develop,  maintain, 
and  operate  software.  The  Technical  Soft¬ 
ware  Management  Group’s  mission  is  to 
efficiently  manage  all  Los  Alamos  National 
Laboratory  Yucca  Mountain  Project  soft¬ 
ware  applications. 

With  the  increasing  complexity  of  software 
applications,  software  components  are  be¬ 
coming  significantly  more  difficult  to 
manage.  Modern  Technical  Software 
Management  and  software  quality  assur¬ 
ance  approaches  require  detailed  informa¬ 
tion  regarding  the  organization  and  inter¬ 
relationships  of  the  components  of  com¬ 
plex  software  applications.  Such  informa¬ 
tion  is  invaluable  for  defining  and  catalog¬ 


ing  software  baselines;  performing  audits 
on  software  development  projects;  creat¬ 
ing  packets  of  information  for  review;  au¬ 
tomating  the  submission,  release,  and 
certification  of  software  products;  gather¬ 
ing  metrics  throughout  the  software 
project;  and  assessing  th-j  scope  and  im¬ 
pact  of  proposed  changes  to  an  application. 

In  order  to  accomplish  these  goals,  a 
mechanism  or  structure  representing  the 
architecture  of  a  complex  software  appli¬ 
cation  must  be  devised  and  the  develop¬ 
ment  of  software  tools  for  processing  the 
architectural  information  must  be 
implemented.  This  structure  is  known  to 
the  Technical  Software  Management 
Group  as  a  file  list.  When  the  file  list  is  de¬ 
fined  and  the  tools  required  to  process  it 
are  in  place,  the  manageability  of  software 
applications  will  increase  and  the  founda¬ 
tion  for  the  development  of  other  software 
configuration  management  and  software 
quality  assurance  tools  will  be  established. 


Software  Applications 

A  software  application  is  a  collection  of 
files  associated  with  either  a  reuse  com¬ 
ponent  or  functionally  related  computer 
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programs.  These  files  are  divided  into  pri* 
mary  components  and  support 
components.  The  primary  components  as¬ 
sociated  with  a  particular  software  applica¬ 
tion  are  composed  of  source  code  mod¬ 
ules  and  documentation  directly  related  to 
the  application.  For  example,  primary 
components  might  consist  of  functionally 
related  computer  programs,  data  sets  re¬ 
quired  for  input  to  obtain  the  data  sets 
required  for  output,  and  possibly  documen¬ 
tation  on  how  to  use  the  program(s).  Sup¬ 
port  components  of  a  software  application 
are  a  group  of  modules  incorporated  into  a 
testing  product.  The  testing  product  con¬ 
stitutes  source  code  modules  and  docu¬ 
mentation  that  are  indirectly  related  to  the 
application.  Examples  of  indirectly  related 
modules  are  testing  files,  each  related  to  a 
different  test  of  the  source  code  modules, 
and  documentation,  explaining  what  is  be¬ 
ing  tested.  Source  code  modules  are  ei¬ 
ther  computer  programs  or  reuse 
components.  The  difference  between 
computer  programs  and  reuse  compo¬ 
nents  is  that  functionally  related  computer 
programs  can  perform  different  tasks 
alone  whereas  reuse  components  are  pro¬ 
cedures  or  functions  that  cannot  stand 
alone  and  must  be  incorporated  into  a  pro¬ 
gram  to  perform  a  variety  of  tasks.  Com¬ 
puter  programs  and  reuse  components  are 
never  combined  in  the  same  software 
application.  The  software  application  is 
comprised  of  modules  directly  or  indirectly 
related  to  the  computer  programs  or  reuse 
components.  Documentation  shall  incor¬ 
porate  significant  events  of  the  develop¬ 
ment  of  a  software  application  and  be  doc¬ 
umented  in  text  files.  These  text  files,  or 
modules,  could  be  user  guides,  reports, 
installation  scripts,  data  set  descriptions, 
modules  and  methods  summaries,  soft¬ 


ware  design  documents,  software  require¬ 
ments  specifications  or  version  description 
documents. 


With  such  a  wide  variety  of  modules  for  a 
single  software  application,  to  manipulate, 
manage,  and  keep  track  of  the  software 
application  and  its  modules  mentally  or 
physically  could  cause  many  errors.  Op¬ 
erating  on  the  software  application  as  a 
single  entity  is  a  necessary  requirement.  It 
is  obvious  that  an  organizational  method¬ 
ology  is  needed  to  maneuver  software 
applications.  The  idea  of  the  file  list  was 
designed  to  fulfill  this  by  Gary  Cort  and 
Steve  Donahue  in  addition  to  aid  the  Tech¬ 
nical  Software  Management  Group  in 
managing  software  applications. 


The  purpose  of  a  file  list  is  to  identify  relat¬ 
ed  components  within  a  software 
application,  k  file  list  is  a  group  of  text 
files.  Each  group  is  again  a  file  list,  which 
identifies  collections  of  functionally  related 
modules  within  a  software  application. 
The  file  list  allows  modules  to  be  logically 
associated  and  controlled  as  a  unit.  The 
file  list  provides  an  organized  scheme  for 
all  software  applications.  With  an  appro¬ 
priate  organization  of  the  software  applica¬ 
tion,  a  hierarchical  structure  is  generated. 

An  entire  software  application  is  represent¬ 
ed  by  a  file  list(Figure  1).  A  file  list  is  an 
abstract  notion  which  decomposes  a  soft¬ 
ware  application  into  collections  of  related 
files.  Each  collection  of  related  files  is  itself 
a  file  list.  An  individual  file  list(Figure  2)  is 
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a  filo  containing  comments  and  names  of 
interdependent  files.  Any  one  of  these  in¬ 
terdependent  file  names  may  also  be  a 
name  of  a  file  list,  representing  a  cluster  of 
names  of  interdependent  files. 

Each  text  file,  or  file  list,  within  the  file  list 
hierarchical  structure  specifies  a  compo¬ 
nent  of  the  software  application.  For  ex¬ 
ample,  suppose  there  exists  a  software 
application,  called  " Program  ."  The  'Pro- 
grant  represents  the  modules  associated 
with  and  including  the  computer  programs; 
input  and  process.  To  convert  the  soft¬ 
ware  application  into  a  file  list,  Program 
now  becomes  PROGRAM.  AFL.  An  Appli¬ 
cation  File  List  (AFL)  provides  the  highest 
level  view  of  a-software  application 
hierarchy.  It  provides  references  to  mod¬ 
ules  that  are  global  to  the  entire  application. 
The  PROGRAM.  AFL  is  a  file  consisting  of 
the  names  of  the  programs;  INPUT.PFL 
and  PROCESS.PFL,  the  testing  product; 
PROGRAM.TFL,  software  requirements 
specification;  PROGRAM.SRS,  and  soft- 
waredesigndocumentation; 
PROGRAM. SDD.  The  architecture  of  an 
AFL  automatically  specifies  the  dependen¬ 
cy  relationships  between  the  primary  and 
support  components.  - 

The  primary  components  represent  the 
Program  File  Lists  (PFLs)  or  the  Reuse 
File  Lists  (RFLs).  In  figure  1 ,  the  Prog-am 
file  list's  primary  components  are  the  com¬ 
puter  programs  INPUT.PFL  and 
PROCESS.PFL.  Becausethe 
PROGRAM. AFL  contains  computer  pro¬ 
grams,  it  cannot  contain  reuse  file 
lists(RFLs).  PFLs  and  RFLs  are  separate 
software  applications.  PFLs  specify  the 
components  of  the  primary  software  prod¬ 
ucts  provided  to  the  users  of  an  application. 


There  is  a  one-to-one  correspondence  be¬ 
tween  PFLs  and  user  programs.  Notice  in 
figure  1  that  INPUT.PFL  and  PROCESS.¬ 
PFL  have  similar  names  listed  within; 
INPUT. ADA  and  PROCESS. ADA.  These 
are  the  names  of  the  user  programs.  Oth- 
er  program  names  listed  within,  i.e. 
I^READ.ADA,  are  support  programs. 
RFLs  specify  the  components  of  the  pri¬ 
mary  reuse  products  provided  to  the  users 
of  an  application.  There  is  a  one-to-one 
correspondence  between  RFLs  and  user 
packages. 

The  support  components  in  the  hierarchi¬ 
cal  structure  are  the  primary  Test  File 
Lists(TFLs).  The  TFLs  are  major  compo¬ 
nents  of  the  overall  testing  effort  and  rep¬ 
resent  the  testing  product.  The  primary 
Test  File  List  shall  reference  zero  or  more 
Test  Suite  Test  File  Lists(TFLs)  and  Sup¬ 
port  File  Lists(SFLs).  The  primary  TFL  will 
also  reference  the  verification  and  valida¬ 
tion  report;  PROGRAM.VVR,  verification 
and  validation  plans  and  procedures; 

.  PROGRAM.  VVP,  and  test  results; 
PROGRAM.TR.  Test  Suite  Test  File  Lists 
and  Support  File  Lists  are  organized  hier¬ 
archically  beneath  the  primary  TFL  to  re¬ 
flect  the  internal  structure  of  the  testing 
effort.  Test  Suite  TFLs  should  be  listed  in 
the  primary  TFL.  The  two  test  suite  TFLs 
listed  in  figure  1  are  INPUT_SUITE.TFL 
and  PROCESS__SUITE.  TFL.  Suite  is  an¬ 
other  word  for  a  collection  of  related  files. 
Itemized  within  are  computer  programs 
and  subprograms  that  are  used  for  testing. 
These  are  only  two  testing  aspects  of  the 
software  application.  There  can  be  many 
Testing  Suite  TFLs  for  one  program  in  or¬ 
der  to  verify  that  the  program  works  cor¬ 
rectly  and  will  not  crash.  There  is  no  limit 
to  the  number  of  Test  Suite  Test  File  Lists 
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This  hierarchical  organization  of  a  file  Bst  that  illustrates  the  decomposition  of  a  program  software  application. 


or  Support  File  Lists  that  may  be  specified 
for  an  application.  A  TFL  at  any  level  may 
reference  Support  File  Lists.  The  one  Sup¬ 
port  File  List  shown  is  TEST_l_SORT.SFL. 
This  contains  information  needed  in  order 
to  run  testing  in  INPUT_SUITE.TFL.  Sup¬ 
port  File  Lists  (SFLs)  are  summarized 
auxiliary  programs  that  provide  additional 
resources  (test  data,  special  environ¬ 
ments,  etc.)  for  the  testing  effort.  There  is  a 
one-to-one  correspondence  of  SFLs  to 
support  programs.  All  file  lists  have  a  spe¬ 
cific  format  that  also  aids  configuration 
management’s  efforts  to  regulate  software. 

File  list  structures  are  made  up  of  entry 
lines  of  information,  either  comments  or 
specifications  (Figure  2).  The  file  list  struc¬ 
ture  has  a  unique  name  and  a  type.  Illus¬ 


trated  in  figure  2,  the  unique  name  is  PRO- 
GRAM  and  type  is  AFL.  A  comment,  de¬ 
limited  by  a  hyphen  in  the  left  margin, 
contains  explanatory  information.  This  in¬ 
formation  could  be  the  name  of  the  soft¬ 
ware  application,  the  description  of  the 
software  application,  or  anything  related  to 
the  software  application.  The  comment  is 
not  processed  by  any  file  list  operations.  It 
is  only  needed  for  user  communication.  A 
specification  characterizes  a  single  mod¬ 
ule  in  terms  of  the  component’s  name, 
type,  and  status.  The  name  is  the  primary 
identification  attribute  of  a  specification.  It 
corresponds  exactly  to  the  file  name  of  the 
associated  application  component  on  the 
host  file  system.  The  type  is  the  extension 
of  the  associated  application  component. 
It  corresponds  to  the  type  of  file  it  is.  In 


Figure  2 


This  program  application  file  list  is  an  example  of  how  a  file  list  is  decomposed. 
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figure  2  examples  of  names  are  PRO¬ 
GRAM,  INPUT  and  PROCESS  and  types 
are  SRS,  SDD,  and  PFL  The  status  spec¬ 
ifies  the  change  processing  status  attribute 
of  an  application  component  through  the 
presence  (or  absence)  of  a  standard  prefix. 
This  attribute  may  assume  one  of  three 
possible  values:  NEW,  MODIFIED,  or 
OLD.  The  status  of  a  component  is  MOD¬ 
IFIED  (prefix  =  *),  if  a  currently  approved 
version  is  undergoing  change.  NEW  sta¬ 
tus  (prefix  =  **)  denotes  a  module  for  which 
no  previous  approved  version  exists.  Sta¬ 
ble  existing  modules  are  assigned  the  OLD 
status  (no  prefix). 


Processing  a  File  List 

Now  that  the  design  has  been  laid,  the 
tools  to  process  the  file  list  must  be 
implemented.  These  tools  were  incorpo¬ 
rated  into  a  software  package.  The  tools 
included:  VISIT_ALL,  VISIT_MODIFIED, 
VISIT_NEW,  VISIT_OLD,  PARENT_OF, 
ANCESTRY_OF,  NAME  OF, 
STATUS_OF,  and  TYPE_OF.  These  tools 
allowed  Technical  Software  Management 
Group  to  efficiently  control  software  appli¬ 
cations  with  minimum  overhead. 

Each  tool  has  a  different  function.  The 
VISIT_ALL  gave  the  ability  to  iterate 
through  an  entire  software  application(fiie 
list).  For  instance,  VISIT_ALL  would  start 
at  the  top  level,  PROGRAM.AFL,  and  re¬ 
turn  one  entry  at  a  time,  PROGRAM.SRS, 
PROGRAM.SDD,  and  PROGRAM.TFL 
(from  figure  1).  When  PROGRAM.TFL  is 
reached ,  the  program  then  branches  off  to 
iterate  through  PROGRAM.  TFL,  returning 
PROGRAM. VVP,  PROGRAM. VVR  and 


then  INPUT_SUITE.TFL.  When  it  reaches 
INPUT_SUITE.TFL,  it  repeats  the  process 
again  until  the  entire  file  list  is  iterated.  The 
VISIT_MODIFIED  procedure  gives  the 
ability  to  iterate  through  only  the  file  names 
that  have  been  modified,  which  means 
that  it  returns  only  modified  entries.  This  is 
the  same  for  VISIT_NEW,  and  VISIT_OLD, 
which  return  new  and  old  entries 
respectively.  The  PARENT_OF  function 
returns  the  name  of  the  file  that  the  file  re¬ 
sides  in.  For  example,  the  parent  of 
PROGRAM.  VVP,  in  figure  1  ,  is 
POG  RAM.  TFL,  andthe  parentof 
P_PRINT.ADA  is  PROCESS. PFL  The 
ANCESTRY_OF  function  returns  the  en¬ 
tire  list  of  ancestors  not  including  the  file 
that  the  ancestry  was  to  be  found  of.  For 
instance,  the  ancestry  of  MAKE_DATA 
would  be  PROGRAM.AFUPROGRAM.TFU 
INPUT_SUITE.  TFUTEST_l_SORT.  SFL. 
The  functions  NAME_OF,  STATUS_OF, 
and  TYPE_OF,  would  return  the  name  sta¬ 
tus  and  type  respectively.  Looking  at  fig¬ 
ure  2,  the  name  of  PROCESS.PFL  would 
be  PROCESS,  the  status  would  be  NEW, 
and  the  type  would  be  PFL 

The  automation  of  this  information  elimi¬ 
nates  routine,  lengthy,  and  inaccurate 
operations.  These  tools  supply  the  data 
necessary  for  the  development  of  other 
software  configuration  management  and 
software  quality  assurance  tools. 

The  Benefits  of  a  File  List 

The  file  list  provides  a  precise  and  clear 
understanding  of  the  organization  of  a  soft¬ 
ware  application.  The  tools  used  to  pro¬ 
cess  a  file  list  can  be  employed  to  obtain 
useful  information.  For  example,  a  printout 
of  a  file  list  can  easily  supply  the  directory 


information  to  store  a  software  baseline,  or 


a  collection  of  software  components. 
When  a  very  large  software  project  is  to  be 
developed,  a  file  list  complements  the  re¬ 
quirements  and  design  document  of  the 
project  and  clarifies  exactly  what  is  to  be 
accomplished.  A  file  list  can  be  held  as  a 
check  list  for  the  physical  and  functional 
requirements  of  software.  For  example,  if 
the  developer  turns  in  a  baseline,  the  con¬ 
figuration  manager  can  cross  check  each 
software  component  handed  in  with  the  file 
list.  This  method  assists  in  tracking  com¬ 
plete  and  needed  to  be  completed  software 
and  documentation.  The  file  list  allows 
assembling  and  printing  of  the  review 
packets  of  information,  which  could  con¬ 
tain  over  a  1,000  different  files,  to  be 
automated.  This  process  can  be  easily  au¬ 
tomated  with  the  VISIT_ALL  procedure, 
which  then  would  requite  only  the  file  list 
name  to  locate,  validate  and  transfer  all  of 
the  files  associated  with  the  baseline; 
therefore,  eliminating  the  tedious  effort  to 
type  each  file  name,  and  quickly  creating  a 
more  accurate  packet  of  information. 

A  file  list  structure  is  also  helpful  for  soft¬ 
ware  updates.  It  would  not  be  beneficial  to 
release  an  entire  software  application  with 
over  a  1 ,000  software  components  to  a  de¬ 
veloper  for  updating,  when  only  a  few  files 
need  to  be  modified.  A  file  list  allows  for 
files  to  be  marked  effectively,  using  the 
status;  NEW,  MODIFIED,  and  OLD.  The 
tools  can  be  used  to  ensure  that  only  the 
necessary  files  are  sent  to  the  developer. 
Since  the  developer  only  has  access  to  the 
software  components  related  to  the  up¬ 
date,  the  configuration  manger  is  still  in 
control  of  the  software  application.  Main¬ 
taining  control  of  the  software  application, 
is  important  for  greater  manageability. 


File  list  structures  also  aid  in  gathering 
metrics  throughout  the  software  project  life 
cycle.  Metrics  aid  software  configuration 
management  in  defining  good,  reliable 
software.  The  process  of  the  software  is 
also  important.  For  instance,  the  number 
of  lines  of  code  in  a  software  component 
can  be  used  to  measure  the  efficiency  of 
the  process.  The  tedious  task,  to  manually 
count  each  line  of  code  would  take  many 
hours  and  include  many  human  errors. 
This  task  can  be  automated  by  the  use  of 
file  list.  By  automating  the  process,  results 
will  be  quick,  efficient,  and  accurate. 


Conclusion 

The  complexity  and  magnitude  of  today's 
software  projects  necessitates  an  en¬ 
hanced,  organized,  and  logical  structure, 
file  list.  File  lists  are  easy  to  maintain  and 
manage.  Using  file  lists  enhances  the  pro¬ 
cesses  of  classifying  and  characterizing 
software  baselines,  verifying  the  require¬ 
ments  of  software  development  projects, 
producing  review  packets,  automating  the 
modification  of  software  products,  obtain¬ 
ing  measurements,  and  determining  the 
range  of  impact  of  proposed  changes.  The 
file  list  insures  a  consistent  hierarchical  or¬ 
ganization  for  the  decomposition  of  a  com¬ 
plex  software  application.  The  automation 
of  these  tools  will  assure  reliable,  precise, 
and  rapid  results  that  will  relieve  the  poor 
soul  of  the  burden  to  be  a  slave  to  the  key 
board.  The  Technical  Software  Manage¬ 
ment  Group  at  LANL  has  put  the  file  list  in 
place  and  created  some  of  the  tools 
mentioned.  They  now  work  on  other  tools 
that  may  assist  them  in  reducing  tedious 
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and  boring  operations  and  improving 
efficiency. 
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Abstract 


We  are  currently  exploring  a  new  approach 
for  introducing  key  software  engineering  and 
computer  science  principles  in  the  second  course 
of  our  curriculum.  Our  approach  introduces 
software  reuse  as  a  context  for  providing  a 
motivation  toward  learning  the  importance  of 
principles  such  as  abstraction,  specification  and 
design.  An  essential  element  for  the  success  of 
the  reuse-based  approach  is  an  appropriate  series 
of  lab  assignments.  First,  We  present  the  students 
with  components  designed  and  implemented  by 
the  lab  instructor.  Based  only  on  the 
specifications,  students  leant  to  assemble  these 
components  and  solve  interesting  problems. 
Later,  students  reuse  these  components  to  build 
layered  implementations  of  other  components. 
Only  toward  the  end  of  thi  course  are  they  taught 
how  to  write  their  own  implementations  from 
scratch,  such  as  using  pointers.  This  paper 
describes  three  lab  assignments  which  illustrate 
our  approach. 

1  Introduction 

Why  teach  reuse  in  an  introdurtnrv  rmtrxttf 

Most  current  undergraduate  computer 
science  curricula  suffer  from  two  fundamental 
problems,  which  often  lead  to  several  others.  One 
problem  is  die  absence  of  a  context,  and  hence 
motivation,  for  learning  fundamental  principles 
of  computer  science  (e.g.  abstraction)  in  the 
second  course.  The  other  problem  is  late 
exposure  to  principles  of  software  engineering, 
such  as  those  found  in  a  senior  level  course, 
resulting  in  relatively  inexperienced  graduates  in 
applying  these  principles. 


We  believe  these  problems  can  be 
ameliorated  by  providing  software  reuse  as  a 
context  in  which  to  teach  the  fundamental 
principles  of  computer  science.  The  reuse-based 
approach  also  motivates  key  software  engineering 
principles  that  are  often  omitted  when  the  course 
is  taught-outside  of  this  context  The  principles 
instilled  by  the  lab  assignments  discussed  in  this 
paper  include: 

-  The  ability  to  understand  abstract  and  formal 
specifications: 

-  Specification-based  component  reuse; 

-  Separation  of  the  specification  of  a 
component  from  its  implementation; 

-  Construction  of  new  components  by  layering 
them  on  top  of  existing  components; 

-  Multiple  implementations  (with  different 
efficiency  characteristics)  for  a  given 
specification. 

Introduction  to  these  principles  early  in 
their  undergraduate  careers  will  give  students 
ample  time  to  gain  confidence  in  their  abilities 
by  applying  the  principles  throughout  their 
remaining  courses.  This  paper  describes  an 
approach  toward  the  construction  of  laboratory 
assignments  which  attempt  to  meet  the  above 
goals.  During  the  past  year,  such  assignments 
have  been  used  in  a  section  of  the  second 
semester  freshmen  level  computer  science  course 
at  the  West  Virginia  University. 
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Our  definition  of  reuse 


Description 


Recent  literature  on  software  reuse 
contains  several  different  definitions  or 
classifications  of  the  term  [6].  The  definition  of 
reuse  used  in  this  paper  is  component-based  [8, 
11].  We  view  a  reusable  component  as  having 
two  distinct  elements:  a  formal  specification  and 
a  certifiable  implementation  of  that  specification, 
possibly  in  the  form  of  object  code.  All 
references  to  reuse  discussed  in  this  paper  are 
based  only  on  the  specification  and  performance 
characteristics  (e.g.  performance  efficiency)  of  the 
implementation.  We  concentrate  on  components 
which  are  designed  for  reuse  and  are  not  concerned 
with  definitions  of  the  term  that  deal  with  code 
scavenging  or  other  methods  where  the 
utilization  of  already  existing  software  occurs  by 
accident  or  serendipity. 

Organisation  tif  the  paper 

The  paper  is  contained  in  five  sections. 
Sections  two  through  four  describe  aspects  of 
different  laboratory  assignments  that  have  been 
used  to  introduce  students  to  software  engineering 
and  reuse  principles.  Each  of  these  sections 
contains  the  goals,  descriptions,  and  possible 
variations  on  the  theme  of  a  particular  lab.  The 
assignments  chosen  to  be  discussed  in  these 
sections  are  only  a  subset  of  the  total  collection 
of  labs  that  we  have  developed  but  are  those 
which  best  exemplify  our  overall  goals.  A  final 
section  summarizes  the  paper  and  offers 
suggestions  for  possible  areas  of  future  work. 

2. Student  as  client  of  a  reusable 

component 


Goals 


To  teach  the  following  principles: 

--  The  ability  to  understand  formal  and  abstract 
expressions  of  a  specification; 

-  Specification-based  component  reuse; 

-  The  need  for  separation  of  the  specification  of 
a  component  from  its  implementation; 

-  Acquaint  the  students  with  the  notation  of  a 
specification  language; 

-  Construction  of  secondary  operations. 


The  purpose  of  this  laboratory  assignment 
is  to  solve  a  backtracking  problem  iteratively 
using  a  stack  package  provided  by  the  instructor. 
Several  different  backtracking  problems  have 
been  introduced  to  the  students.  Examples  of 
problems  we  have  used  in  the  past  include: 

--  The  Eight  Queens  problem,  whereby  the 
students  must  find  all  possible  combinations 
of  placing  eight  queens  on  a  chess  board  so 
that  no  queen  can  be  attacked  by  another, 

-  Helping  a  mouse  find  a  piece  of  cheese  by 
moving  through  a  maze  which  contains  dead¬ 
ends; 

-  Assisting  a  squirrel  in  climbing  to  the  top  of 
a  tree,  filled  with  many  empty  branches,  to 
find  an  acorn. 

All  of  the  above  problems  share  a  common  trait 
in  that  a  decision  must  be  made  to  explore  down 
one  of  several  paths.  Also,  an  ability  must  be 
provided  so  that  one  can  backtrack  to  previous 
spots  and  choose  alternative  paths  when  dead-ends 
are  encountered. 

The  students  are  asked  to  solve  these 
problems  iteratively  using  a  stack.  The 
specification  of  an  Ada  package  that  provides  a 
stack  component  is  shown  in  Figure  1.  The 
students  are  given  a  copy  of  this  specification  and 
told  how  to  access  the  object  code  version  of  the 
body  to  allow  for  proper  linking.  They  must 
construct  a  client  program  which  utilizes  the 
stack  package  to  solve  the  backtracking  problem. 
The  client  program  is  then  linked  with  the  stack 
package  to  obtain  an  executable. 


When  the  students  are  given  the  stack 
component,  they  are  asked  to  view  the 
specification  as  a  contract  between  themselves 
and  the  implementer  of  the  package  (i.e.  the  lab 
instructor).  This  reinforces  the  notion  that  the 
developer  and  user  of  a  component  are  often 
different  people.  They  are  assured  that  the  stack 
operations  will  work  correctly  provided  they 
follow  the  specification.  They  must  surmise  on 
their  own,  by  reading  the  specification,  the 
syntax  and  meaning  of  each  operation.  Thus,  the 
students  get  an  early  example  of  the  importance 
of  providing  specifications  which  are 
unambiguous.  To  add  semantic  information  to 
Ada  package  specifications,  we  use  a  close  dialect 
of  the  RESOLVE  specification  language  [4,  10, 
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1 1],  RESOLVE  specifications  are  formal,  but  yet 
succinct  and  understandable  by  freshmen  who 
have  been  briefly  exposed  to  topics  covered  in 
discrete  mathematics. 

In  Figure  1,  the  type  Stack  is  modeled  as  a 
mathematical  string.  Manipulations  on  a  variable 
of  type  Stack  are  described  using  functions 
borrowed  from  mathematical  string  theory  (e.g. 
the  concatenation  operator  «*  "o“,  found  in  the 
Push  and  Pop  operations).  Operations  are 
specified  using  a  requires  clause  (pre-condition) 
and  an  ensures  clause  (post-condition).  Some 
operations  may  not  have  a  requires  clause.  These 
clauses  are  mathematical  assertions  and  not 
executable  statements.  The  requires  clause  states 
what  needs  to  be  true  before  the  operation  is 
called  while  the  ensures  clause  states  what  the 
operation  will  do  provided  the  requires  clause  is 
satisfied  at  call  time.  A  call  to  an  operation 
without  satisfying  the  requires  clause  is  undefined 
and  can  do  anything.  Each  reference  to  a  variable 
in  the  requires  clause  refers  to  the  value  of  the 
variable  at  the  time  the  procedure  was  invoked.  In 
the  ensures  clause,  however,  the  value  of  a 
variable  at  the  time  of  procedure  invocation  is 
accessed  by  preceding  the  variable  name  with  a 
sign.  Reference  to  a  variable  without  the  '#'  sign 
refers  to  its  value  at  the  time  the  operation 
returns  to  the  caller.  Also,  since  most  character 
sets,  including  ASCII,  do  not  provided  symbols 
for  the  universal  quantifiers  or  lambda  (i.e.  the 
empty  string  in  our  specification),  we  resort  to 
spelling  out  the  definition  of  these  symbols 
rather  than  giving  the  symbol  itself.  Aside  from 
an  explanation  of  the  concatenation  operator, 
which  should  be  familiar  to  most  readers,  the 
above  discussion  provides  an  individual  with 
enough  detail  to  comprehend  the  meaning  of  each 
operation.  One  can  simply  view  the  stack 
operations  as  manipulations  on  a  string  whereby 
calls  to  the  Push  operation  "consume"  an  item 
and  place  it  at  the  end  of  a  string  (i.e.  S  *  #S  o 
X);  the  returned  item  is  assigned  an  initial  value 
depending  on  the  type  of  the  item.  Calls  to  the 
Pop  operation  remove  an  item  from  the  end  of 
the  string  (i.e.  #S  *  S  o  X). 

The  Basic_Stack_Template  has  been 
designed  for  reuse  by  following  guidelines  such 
as  those  in  [4).  There  are  several  differences 
between  specifications  designed  using  these 
guidelines  and  other  specifications  found  in 
discussions  like  [1].  Details  of  these  design 
issues  are  beyond  the  scope  of  this  paper.  An 
interested  reader  is  referred  to  [2, 4, 5, 8, 1 1]  for 
more  detailed  descriptions  of  design  issues  such 
as  why  standard  operations  called  Initialize, 


Finalize,  and  Swap  are  provided  for  every  type, 
generic 

type  T  is  limited  private; 

with  procedure  T_lnitialize(X  :  In  out  T); 
-I  ensures  T.Init(X) 

with  procedure  T_Finalize(X  :  in  out  T); 

with  procedure  T_Swap(X,  >  :  in  out  T); 
-!  ensures  (X  -  #Y)  and  (Y  -  #X) 

package  Basic_Stack_Template  is 

type  Stack  is  limited  private; 

--!  type  Stack  is  modeled  by  a  string  of  T... 

-  standard  operations... 

procedure  Initialize^  :  in  out  S"v:k); 

••1  ensures  S  =  Lambda 

procedure  FinaIizc(S  :  in  out  Stac' ); 

procedure  Swap(Sl,  S2  :  in  out  S  ick); 

-1  ensures  (S 1  =  #S2)  and  (S2  =  #S  1) 

-  primary  Stack  operations... 

procedure  Push(S  :  in  out  Stack; 

X  :  in  out  T); 

--!  ensures  (S  =  #S  o  X)  and  T.Init(X) 

procedure  Pop(S  :  In  out  Stack; 

X  :  in  out  T); 

-!  requires  S  h  Lambda 

-1  ensures  #S  *  S  o  X  1 

function  Is_Empty(S  :  Stack) 

return  Boolean; 

--!  ensures  Is_Empty  iff  S  ■  Lambda 
private 

type  Representation; 

type  Stack  is  access  Representation; 

end  Basic_Stack_Template; 

Figure  1 

Specification  of  a  Stack  Component 

A  find  requirement  of  the  assignment  is 
to  construct  what  are  termed  secondary  operations 
for  the  component  Secondary  operations  provide 
additional  functionality  in  using  a  particular 
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component.  These  operations  are  often  not 
included  in  the  list  of  primary  operations  due  to 
tlie  fact  that  they  can  be  implemented  efficiently 
without  underlying  knowledge  of  the  abstract  data 
type  representation.  To  illustute  the  difference, 
the  implementation  of  the  primary  stack 
operation  called  Push  must  have  access  to  the 
underlying  representation  of  a  stack  in  order  to 
properly  add  an  element.  It  needs  to  know 
whether  the  stack  is  being  represented  using 
pointers,  arrays,  or  layered  on  top  of  some  other 
component.  However,  a  secondary  operation 
called  Copy_Stack,  for  instance,  does  not  need 
access  to  the  representation  and  can  be  written 
simply  using  a  loop  with  proper  calls  to  the 
primary  operations  Pop  and  Push,  in  addition  to 
the  possible  need  of  temporary  variables. 

The  assignment  directs  the  student  in 
assembling  two  secondary  operations  for  stacks. 
The  operations  that  the  student  must  write  are 
Reversc_Stack  and  Print_Stack.  These  operations 
are  needed  in  the  assignment  to  print  the  actual 
solutions  to  the  problem  that  the  client  program 
discovers.  Since  the  secondary  operations  require 
access  to  various  primary  operations,  the  needed 
primary  operations  must  be  passed  as  generic 
parameters.  An  example  of  how  this  might  be 
accomplished  is  found  in  Figure  2.  All  the 
standard  (i.e.  Initialize,  Finalize,  and  Swap)  and 
primary  operations  of  both  the  element  type  T 
and  the  Stack  type  are  passed  as  generic 
parameters. 

generic 

-  Semantic  specifications  for  the  following 

—  operations  are  the  same  as  those  found  in 
~  Figure  1. 

type  T  is  limited  private; 

with  procedure  T_Init(X  :  in  out  T); 
with  procedure  T_Fin(X  :  in  out  T); 
with  procedure  T_Swap(X,  Y  :  in  out  T); 
with  procedure  T_Print(X  :  in  out  T); 

type  Stack  is  limited  private; 

with  procedure  Initialize^  ;  in  out  Stack); 
with  procedure  Finalize(S  :  in  out  Stack); 
with  procedure  Swap(R,  S  :  in.  out  Stack); 
with  procedure  Push(S:  in  out  Stack; 

X:  in  out  T); 

with  procedure  Pop(S:  in  out  Stack; 

X:  in  out  T); 

with  function  Is_Empty(S:  in  Stack) 

return  Boolean; 


package  Secondary _Stack_Ops  is 

--  secondary  operations... 

procedure  Reverse_Stack(S  :  in  out  Stack); 
“!  ensures  S  =  #S^ 

procedure  Print_Stack(S  :  in  out  Stack); 

--!  ensures  (S  =  #S)  and  (output  =  S) 

end  Secondary_Stack_Ops; 

Figure  2 

Specification  of  a  Component  for 
Secondary  Stack  Operations 

Variations 

As  stated  above,  there  arc  three  variations 
to  the  backtracking  problem  which  we  have  used 
as  laboratory  assignments.  Similar  labs  that 
make  use  of  abstract  data  types  other  than  a  stack 
could  be  developed.  For  example,  a  lab  instructor 
might  give  the  students  a  queue  package  and  ask 
them  to  write  a  client  program  that  uses  the 
component.  They  might  be  asked  to  use  the 
queue  to  simulate  a  message  passing  system 
where  requests  to  send  and  receive  messages  are 
handled  and  placed  on  a  queue.  Alternatively,  they 
might  use  the  queue  to  simulate  a  row  of  tellers 
at  a  bank  where  each  teller  has  a  queue  of 
customers  with  individual  requests  to  be  serviced. 


Goals 


This  lab  instills  the  following  principles, 
in  addition  to  those  already  named  in  section  two: 

-  Construction  of  new  components  by 
layering  them  on  top  of  existing 
components; 

-  Multiple,  plug-compatible, 
implementations  (with  different 
efficiency  characteristics)  for  a  given 
specification. 

Description 

This  section  describes  an  assignment  that 
is  along  the  same  idea  as  the  last  section  but 
offers  somewhat  of  a  change  in  the 
implementation  of  the  stack  package.  In  this 
assignment,  the  students  are  given  the 
specification  to  a  list  component  shown  in 
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Figure  3.  Implementation  details  about  this 
component  are  hidden  but  access  to  the  object 
code  is  provided  to  allow  linking.  They  are  then 
asked  to  use  this  component  to  actually 
implement  the  operations  of  the  stack  package 
which  they  have  already  seen  and  used.  They 
must  implement  the  stack  operations  solely  by 
making  calls  to  the  operations  of  Figure  3  and 
are  not  allowed  to  use  any  form  of  pointers  or 
array  constructs.  Thus,  a  stack  package  is 
implemented  by  layering  it  on  top  of  another 
component  The  lab  described  in  the  previous 
section  is  reused  in  this  case  by  re-linking  it  with 
the  new  stack  implementation.  The  assignment 
should  assist  the  students  in  beginning  to  think 
about  how  multiple  implementations  for  the 
same  specification  are  constructed  (see  [9]).  Also, 
the  ease  with  which  this  lab  can  be  completed 
should  reinforce  the  idea  of  reuse.  Students  learn 
that  it  is  often  advantageous  to  make  use  of  pre¬ 
existing  standard  components  rather  than  "re¬ 
inventing  the  wheel". 

The  concept  used  to  represent  the  list 
component  in  Figure  3  is  different  from  the 
typical  list  concept  presented  in  textbooks  like 
[1],  In  particular,  the  abstract  idea  of  lists  is 
presented  without  discussing  pointers  or  access 
types.  A  type  called  list  is  modeled  as  two 
strings  of  some  other  type  T.  These  two  string 
are  called,  appropriately,  "left"  and  "right".  This 
view  can  be  better  understood  if  one  envisions  a 
conceptual  cursor  that  separates  the  two  strings. 
The  package  provides  operations  to  move  this 
cursor  around  the  list  as  well  as  the  ability  to 
perform  insertions  and  deletions.  To  illustrate 
this  notion  of  a  cursor,  as  it  would  apply  to  a 
list,  examine  the  following  instance  of  a  list 
variable  called  L: 


I 

3417263 

I 

The  value  of  L.Left  would  contain  the  two 
elements  3  and  4  while  the  value  of  L.Right 
would  contain  the  four  values  7, 2, 6,  and  3.  All 
insertions  and  deletions  are  performed  to  the  right 
of  the  cursor.  The  Reset  and  Advance  operations 
are  used  to  traverse  through  the  list  Using  the 
above  values  of  list  L,  a  call  to  the  Reset 
operation,  followed  by  a  call  to  Remove  would 
result  in  L  now  resembling  the  following: 

I 

147263 

I 


As  a  design  principle,  functions  needed  to  check 
the  requires  clause  of  all  operations  are  also 
included  in  the  specification  (i.e.  function 
At_Right_End).  The  operation  SwapJRight  will 
not  be  used  in  this  assignment.  It  has  been 
provided  for  future  assignments  that  may 
implement  secondary  operations  since  it  has  been 
found  useful  in  constructing  efficient 
implementations  of  a  Copy.List  operation  [1 1]. 

The  students  have  often  found  that  this 
assignment  can  be  completed  within  several 
hours.  Almost  all  of  the  required  stack  operations 
that  they  must  write  can  be  implemented  with 
merely  one  line  of  code.  For  example,  code  to 
implement  the  Push  operation  would  simply 
entail  making  the  proper  call  to  a  corresponding 
list  operation  (i.e.  Insert).  Similar  reasoning 
follows  for  the  other  stack  operations  provided 
the  students  take  care  to  preserve  the  FIFO 
ordering  of  the  stack.  A  student  only  needs  to 
understand  the  specification  of  the  list  component 
well  enough  to  discern  what  calls  correspond  to 
similar  notions  within  the  stack  operations.  This 
reinforces  the  concept  of  specification-based 
component  reuse. 

generic 

type  T  is  limited  private: 

with  procedure  T_InitiaIize(X  :  in  out  T); 

--!  ensures  T.Init(X) 

with  procedure  T_Finalize(X  :  in  out  T); 

with  procedure  T  Swap(X,  Y  :  in  out  T): 

~!  ensures  (X  =  #Y)  and  (Y  =  #X) 

package  Lists  is 

type  List  is  limited  private; 

-  type  List  is  modeled  by  a  pair  of  strings  of  T, 

-  named  Left  and  Right 


procedure  Initialize^:  in  out  List); 

••!  ensures  (L.Left  a  Lambda)  and 
-  \  (L .Right  a  Lambda) 

procedure  Finalize(L:  in  out  List); 

procedure  Swap(Ll,  L2:  in  out  List); 

*•!  ensures  (LI  a#L2)and(L2«#Ll) 

Eiamx-3 
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-  primary  List  operations 


procedure  Rcsct(L:  in  out  List); 

— !  ensures  (L.Left  =  Lambda)  and 

--!  (L.Right  =  #L.t.cfl  o  trL.Right) 

procedure  Advancc(L:  in  out  List); 

--!  requires  L.Right  /=  Lambda 
••!  ensures : 

--!  (L.Lel't  o  L.Right  =  #L.l,eft  o  #L.Right)  and 
--!  (thereExists  x:  T,  s.t.,  L.Left  =  #L.Lcft  o  x) 

function  At_Righl_End(L:  in  List) 

return  Itoolean; 
— !  ensures  At_Right_End  iff  L.Right  =  Lambda 

procedure  Inscrt(L:  in  out  List; 

X:  in  out  T); 

--!  ensures  (L.Left  =  #L.Lcft)  anti 

-*!  (L.Right  =  X  o  #L.Right)  and  T.init(X) 

procedure  Remove(L:  in  out  List; 

X:  in  out  Item); 

--!  requires  L.Right  /=  Lambda 
--!  ensures  (L.Left  =  #L.Lcft)  and 
••!  (#L.Right  =  X  o  L.Right) 

procedure  Swap_Right(Ll  :  in  out  List; 

L2  ;  in  out  List); 

--!  ensures  (LI. Left  =  #Ll.Left)  and 
-*!  (L2.Left  =  #L2.Lcft)  and 
--!  (Ll.Right  =  #L2. Right)  and 
••!  (L2.Right  =  #Ll.Right) 

private 

type  Representation; 

type  List  is  access  Representation; 

end  Lists; 

Figure  3  front.) 

Specification  of  a  List  Component 

Variationx 

Although  the  above  description  layers  a 
stack  package  on  top  of  a  pre-existing  list 
component,  it  is  certainly  plausible  that  one 
could  also  use  alternative  abstract  data  types.  For 
instance,  the  students  might  be  asked  to 
implement  a  stack  layered  upon  a  deque  or  a 
standard  FIFO  queue  rather  than  a  list.  Tbey  also 
could  be  asked  to  analyze  the  efficiency  of  each 
operation  in  comparison  to  other  strategics.  As 
an  example  using  a  FIFO  queue  to  build  a  stack, 
if  the  push  operation  executes  in  constant  time, 
then  the  pop  operation  must  run  in  linear  time 


due  to  the  need  to  retrieve  the  clement  at  the  end 
of  the  queue  since  the  ordering  of  the  two  data 
structures  (i.c.  FIFO  versus  LIFO)  differs. 

4  Student  as  an  imnternentcr  of  a 
maafrle-jcumpwicnt  imiit 

from-scratch 

Gouts 

In  addition  to  the  principles  named  in 
sections  two  and  three,  this  lab  introduces  the 
following  new  concept: 

—  Use  of  access  types  u>  efficiently  implement 
components  from-scratch. 

Description 

This  section  describes  variations  to  a 
laboratory  assignment  that  is  often  presented 
toward  the  end  of  a  semester.  It  tends  to  focus 
more  on  specific  details  of  implementing 
components  (c.g.  using  pointers).  It  builds  upon 
the  previous  two  discussions  by  requiring  the 
students  to  finally  write  lower  level 
implementations  of  the  list  component.  The 
stack  package  will  still  be  layered  on  top  of  the 
list  but  in  this  case  the  students  acquire  a  feel  for 
using  access  types  to  represent  unbounded 
components. 

Yadations 

Several  possible  variations  could  be 
suggested  toward  implementing  the  list  in  ways 
other  than  pointers.  The  list  itself  could  be 
layered  upon  an  already  assembled  component  or 
the  implementation  details  might  opt  to  focus  on 
an  array  based  approach.  Additionally,  rather  than 
concentrating  on  using  a  list  to  construct  the 
stack  as  in  section  three,  the  idea  of  pointers 
could  be  used  to  implement  the  stack  directly 
which  would  allow  one  to  eliminate  the  need  for 
implementing  lists  altogether.  Also,  secondary 
operations  for  lists  could  be  requested  similar  to 
those  described  in  the  first  assignment.  Students 
might  be  asked  to  implement  a  secondary 
operation  which  performs  a  Copy_List,  using  the 
primary  Swap_Right  operation,  from  one  list 
variable  to  another  variable.  Correspondingly,  the 
students  may  be  asked  to  write  secondary 
operations  for  the  list  package  to  provide  the 
facilities  for  printing  and  reversing  lists. 

A  proviso  could  be  added  to  the 
assignment  which  states  that  all  primary 
operations  need  to  be  written  in  constant  time. 
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This  would  be  mentioned  in  conjunction  with  a 
statement  reminding  them  that  the  implementer 
and  client  of  a  component  are  often  different 
individuals.  With  this  in  mind,  the  students  will 
come  to  realize  the  need  for  efficient 
implementations  since  the  client  will  probably 
decide  to  rewrite  the  component  themselves  from 
scratch  if  the  component  does  not  meet  their 
performance  requirements.  In  this  paper  we  do 
not  go  into  any  details  on  hew  the  list  operations 
are  constructed  in  constant  time  but  additional 
information  on  implementing  unbounded 
reusable  components  can  be  found  in  [3]. 

S  Conclusions 

The  structure  of  most  current  curricula 
tends  to  introduce  the  fundamental  principles  of 
computer  science  void  of  any  particular  context 
An  introductory  course  based  on  a  software  reuse 
setting  would  assist  in  providing  a  needed  context 
to  introduce  these  principles.  Gariy  exposure  to 
these  principles  would  aid  students  in  applying 
the  ideas  toward  a  vast  majority  of  the 
programming  projects  that  they  would  encounter 
throughout  the  remainder  of  their  undergraduate 
careers. 

In  this  paper  we  presented  one  approach 
toward  providing  a  context  for  teaching  the 
fundamental  principles  of  computer  science.  With 
our  approach,  laboratory  assignments  are  used  to 
inculcate  the  fundamental  principles  of  computer 
science  whereby  software  reuse  is  used  as  a 
primary  motivator.  As  examples,  a  subset  of  our 
laboratory  assignments  currently  used  at  the  West 
Virginia  University  were  described.  These 
assignments  first  require  the  student  to  become  a 
client  of  reusable  components.  Later  in  the 
semester  they  are  given  the  opportunity  to 
actually  implement  their  own  components  at  a 
lower-level  (e.g.  using  pointers). 

There  is  still  much  work  that  needs  to  be 
done  with  the  implementation  of  our  approach. 
For  example,  most  of  the  proposed  laboratory 
assignments  that  were  mentioned  under  the 
Variations  sections  need  to  be  constructed.  We 
are  also  currently  working  toward  conducting  a 
survey  to  determine  the  impact  of  the  reuse-based 
approach  as  being  applied  by  previous  students  in 
other  courses  in  our  curriculum. 
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Summary 

v  (TE  is  the  Command  and  Control  domain  contractor 
lor  DARPA’s  Domain  Specific  Software 
Architectures  program.  The  objective  of  this  program 
is  to  develop  and  demonstrate  an  architecture-driven, 
component -based  capability  for  the  automated 
generation  of  command  and  control  (C2)  applications. 
Such  a  capability  will  significantly  reduce  the  cost  of 
C2  application  development  and  will  lead  to 
improved  system  quality  and  reliability  through  the 
use  of  proven  architectures  and  components.  This 
paper  describes  GTE’s  approach  to  the  program, 
focusing  in  particular  on  the  domain-specific  reuse- 
based  software  lifecycle. 

IbfcPggAjCfiPWPt 

DSSA  is  based  on  the  concept  of  an  accepted  generic 
software  architecture  for  the  target  domain.  As 
defined  by  DSSA.  a  software  architecture  describes 
the  topology  of  software  components,  specifics  the 
component  interfaces,  and  identifies  computational 
models  associated  with  those  components,  The 
architecture  must  apply  to  a  wide  range  of  systems  in 
the  chosen  domain;  thus  it  must  be  general  and 
flexible.  It  must  be  established  with  the  consensus  of 
practitioners  in  the  domain. 

Once  an  architecture  is  established,  components  that 
conform  to  the  architecture — i.e.,  that  Implement 
elements  of  its  functionality  in  conformance  with  its 
Interfaces— will  be  acquired  They  may  be  acquired 


by  identifying  and  modifying  (if  required)  existing 
components  or  by  specifically  creating  them. 

The  existence  of  a  domain-specific  architecture  and 
conformant  component  base  will  dictate  a 
significantly  different  approach  to  software 
application  development.  The  developer  will  not  wait 
until  detailed  design  or  implementation  to  search  for 
reuse  opportunities;  instead,  he/she  will  be  driven  by 
the  architecture  throughout.  The  architecture  and 
component  base  will  help  define  requirements  and 
allow  construction  of  rapid  prototypes.  Design  will 
use  the  architecture  as  a  suiting  point.  Design  and 
development  tools  will  be  automated  to  “walk 
through”  the  architecture  and  assist  the  developer  in 
the  selection  of  appropriate  components.  The  ultimate 
goal  is  to  significantly  automate  the  generation  of 
applications.  A  major  DSSA  task  is  to  define  such  a 
software  lifecycle  model  and  to  prototype  a 
supporting  toolset. 

These  activities  arc  accompanied  by  extensive 
interaction  with  the  development  community  for  the 
target  domain,  and  by  technology  transition  activities. 
One  aspect  of  this  is  that  each  domain  team  is  working 
closely  with  a  DoD  agency  that  carries  out  major 
developments  in  the  designated  area.  The  GTE  team 
Is  working  with  the  US  Army  Communications  and 
Electronics  Command. 

mxX^mmanland Control? 

There  arc  many  reasons  why  the  command  and 
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control  domain  is  an  excellent  target  for  DSSA 
technology.  It  is  a  high  payoff  area;  command  and 
control  systems  are  needed  even  in  the  current 
military  climate.  (This  is  particularly  true  when  one 
recognizes  that  applications  such  as  drug  interdiction 
and  emergency  relief  fall  within  the  C2  “umbrella".) 
It  is  a  well-understood  area;  most  of  the  processing 
performed  in  C2  applications  is  not  algorithmically 
complex.  However,  C2  applications  are  very  large, 
and  much  of  this  size  comes  from  repeated  similar 
processing — for  example,  parsing  hundreds  of  types 
of  messages.  In  addition  to  this  commonality  within 
applications,  there  is  much  commonality  across 
applications.  Multiple  C2  systems  must  handle  the 
same  message  types,  display  the  same  kinds  of  world 
maps,  etc. 


The  kinds  of  commonality  in  C2  applications  arc  very 
well-suited  to  DSSA  techniques.  In  some  areas, 
components  can  be  reused  identically;  these  can  be 
placed  in  the  DSSA  component  base  and  highly 
optimized.  In  other  areas,  components  will  be  very 
similar  in  nature  but  differ  in  the  particulars,  e.g., 
message  parsing.  These  areas  arc  a  natural  fit  to  the 
DSSA  component  generation  technology,  allowing  a 
table-driven  generator  to  quickly  create  the  needed 
specific  component  instances. 

GTE’s  Approach 

Figure  1  illustrates  GTE’s  overall  approach  to  the 
DSSA  program. 

Initially,  project  work  follows  two  parallel  threads. 


Figure  1.  GTE’s  DSSA  Approach 


The  first  is  defining  a  software  lifecycle  process 
model  appropriate  to  architecture-driven  software 
development  and  developing  a  toolset  to  support  that 
process.  The  second  is  establishing  a  capability  that 
implements  the  process  for  the  command  and  control 
domain,  based  on  a  C2  architecture  and  a  set  of 
reusable  C2  components. 

The  DSSA  process  model  addresses  all  aspects  of  the 
software  life  cycle.  It  describes  activities  for 
establishing  system  requirements,  developing  the 
software  system,  and  sustaining  the  system  after 
delivery.  The  detailed  process  model  identifies  roles 
of  government  (e.g.,  PEOs,  PMs),  developers, 
maintained,  and  reuse  library  organizations  in  an 
architecture-driven,  reuse-based  lifecycle. 

The  DSSA  toolset  will  support  all  of  these  activities, 
automating  them  as  far  as  possible.  In  particular,  it 
will  automate  system  development  activities  by  using 
the  architecture  as  a  template,  guiding  the  selection  of 
available  reusable  components,  and  automating  the 
generation  of  specific  required  components.  The 
toolset  will  be  constructed  insofar  as  possible  from 
available  tools — both  commercial  products  and 
products  of  the  research  community.  In  particular,  it 
will  make  use  of  USC/Information  Sciences 
Institute’s  APS  application  generator,  DARPA/ 
STARS  reuse  libraries,  and  DARPA/Prototech  tools. 
Open  tool  interfaces  will  be  emphasized  to  minimize 
specific  tool  dependencies,  thus  making  the  toolset 
usable  in  the  widest  range  of  environments 

Fundamental  to  the  C2  DSSA  capability  is  the 
development  of  a  C2  software  architecture.  This 
starts  with  development  of  a  multi-viewpoint  domain 
model,  created  through  interaction  with  all  elements 
of  the  DoD  C2  community.  Tools/methods  used  in 
modeling  include  IDEFO,  Requirements  Driven 
Development  (RDD),  and  OMT  object  modeling. 
From  this  set  of  models,  an  object-oriented  software 
architecture  is  being  developed.  The  architecture  will 
tie  back  to  the  multi-viewpoint  model  so  that 
mappings  to  different  views  of  the  domain  functional 
decomposition  arc  apparent.  (George  Mason 
University’s  Center  for  C3I  is  playing  a  major  part  in 
this  modeling  and  consensus-building  activity.)  A 
base  of  components  conforming  to  the  architecture 
will  then  be  developed.  Many  of  these  will  be 
existing  components,  perhaps  modified  to  fit  the 


architecture.  Others  will  be  automatically  generated 
using  APS. 

The  DSSA  capability  will  be  demonstrated  by 
development  of  a  prototype  C2  subsystem,  most 
likely  from  the  fire  support  area.  An  independent 
metrics/validation  task  will  assess  the  effectiveness  of 
the  approach  and  gather  metrics.  The  methodology 
and  toolset  will  be  revised  based  on  findings  and 
further  necessary  research  will  be  identified. 

Throughout  the  program,  a  technology  transfer  task 
will  present  results  in  conferences,  papers,  seminars, 
and  short  courses.  The  George  Mason  University 
Center  for  C3I  will  serve  as  a  focal  point  for 
technology  transfer. 


Figure  2  presents  an  overview  of  the  DSSA  lifecycle. 
The  shaded  boxes  in  the  figure  represent  architecture 
development  activities  and  products.  These  establish 
the  basis  for  subsequent  development  of  specific 
applications  in  the  domain.  The  domain  reference 
requirements  define  the  functional  and  performance 
requirements  that  characterize  systems  in  the  domain. 
These  are  then  mapped  to  a  reference  architecture  for 
the  domain — a  generic  architecture  that  can  be 
adapted  to  build  specific  systems. 

Components  that  conform  to  the  reference 
architecture  are  then  developed  and/or  acquired  and 
cataloged  in  a  reusable  component  library. 

The  clear  boxes  in  the  figure  represent  the  activities 
and  products  of  target  system  generation.  These  are 
the  activities  in  which  a  developer  of  a  specific  system 
makes  use  of  the  architecture  products  to  construct 
that  system.  First,  through  a  process  of  requirements 
elicitation,  the  target  system  requirements  are 
analyzed  and  expressed  in  terms  of  the  reference 
requirements  model.  Then,  based  on  this 
correspondence,  the  reference  architecture  is 
instantiated  (adapted,  filled  in,  modified  as  necessary) 
to  create  a  design  architecture  for  the  specific  system 
to  be  developed.  Components  from  the  library  are 
then  used  to  realize  the  design — i.e.,  to  create  the 
target  system  implementation.  The  design,  as  it  is 
based  on  the  same  architecture  that  formed  the  basis 
for  the  component  collection,  largely  automates  the 
component  idcntification/selection  process. 
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Figure  2.  The  DSSA  Life  Cycle  Model 


The  DSSA  framework  also  establishes  a  natural  basis 
for  construction  of  executable  prototypes  and 
simulations.  Such  prototypes  can  be  constructed  from 
the  reference  architecture  and  library  components  in 
order  to  help  refine  requirements  and  assess 
performance.  The  following  sections  describe  DSSA 
roles  and  processes  in  more  detail. 

DSSA  Roles  and  Agents 

As  part  of  understanding  the  DSSA  development 
process,  it  is  important  to  understand  the  kinds  of 
individuals  and  organizations  that  participate  in  the 
process.  In  this  characterization,  we  adopted 


descriptive  terminology  used  by  the  Software 
Engineering  Institute’s  process  description  project 
This  approach  begins  by  defining  process  roles  and 
agents. 

DSSA  Roles 

A  role  is  a  uniquely-identified  class  of  individuals 
based  on  qualification,  skills,  or  responsibilities  that 
perform  specific  activities  in  the  process.  In  addition 
to  the  traditional  software  development  roles,  the 
DSSA  process  defines  two  new  roles: 

The  Domain  Exoen.  The  domain  expert  is  an 
individual  who  has  wide  experience  in  applications 
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that  distinguish  this  domain.  Tb  be  considered  an 
“expert"  for  this  domain,  the  individual  should  be  able 
to  express  application  requirements  in  the  framework 
of  a  modeling  technique  intrinsic  to  the  DSSA 
development  environment.  In  addition,  the 
requirements  that  are  most  critical  for  the  domain 
expert  are  those  that  reflect  a  complete  understanding 
of  end  user  needs.  Evaluation  of  design  decisions  by 
the  domain  expert  should  reflect  the  user’s 
perspective. 

Domain  experts  help  define  and  model  the  reference 
requirements  and  continue  to  be  a  resource  for 
evaluation  and  enhancement  of  applications.  They 
arc  in  communication  with  and  represent  the  needs  of 
the  end  user.  Example  domain  experts  might  be 
military  requirements  developers  in  organizations 
such  as  TRADOC.  In  the  commercial  world,  they 
might  be  people  in  a  vendor’s  marketing  organization 
who  specify  what  the  market  wants  and  set  the 
direction  for  future  products. 

An  experienced  software  engineer  would  not  be 
considered  a  domain  expert  on  the  strength  of 
development  of  applications  in  the  domain  alone;  he 
or  she  would  need  expert  knowledge  of  the  end  user’s 
future  as  well  as  present  needs.  Domain  experts  most 
likely  would  have  been  end  users  themselves  at  one 
time. 

The  Domain  Architect.  The  domain  architect  is  a 
system/software  engineer  who  has  significant 
experience  developing  applications  in  this  domain  but 
does  not  necessarily  have  the  domain  expert’s 
understanding  of  user  needs.  This  individual  must 
have  in-depth  knowledge  of  all  aspects  of  the  DSSA 
process  and  products.  Tbgether  with  the  domain 
expert,  the  domain  architect  elicits  and  models 
domain  requirements.  In  addition,  it  is  his  or  her  task 
to  transform  the  reference  requirements  to  a  reference 
architecture  for  the  DSSA  environment  Besides  the 
models  of  the  reference  requirements,  the  assets 
available  to  the  domain  arcliitect  would  include: 
consensus  models,  component  class  specifications, 
and  reusable  components. 

The  domain  architect’s  products  are  continually 
evolving  through  feedback,  evaluation,  and 
restructuring  of  the  environment  in  addition  to  the 
normal  system  maintenance  functions.  Maintenance 
is  much  more  complex  in  DSSA  than  in  traditional 


software  procedures,  as  we  will  note  later. 

DSSA  Agents 

An  agent  is  an  entity  that  enacts  or  participates  in  a 
DSSA  process.  An  agent  may  be  an  organization  or 
a  designated  role  within  an  organization. 

Domain  Manager.  The  organization  managing  a 
family  of  related  systems  within  a  DSSA  domain  is 
referred  to  as  the  domain  manager.  This  is  the 
organization  that  will  gain  directly  from  the  common 
technology  base  of  a  domain-specific  software 
architecture.  For  example,  a  military  Program 
Executive  Office  (PEO)  might  be  a  domain  manager. 
In  industry,  a  business  arc  or  program  office  manager 
might  be  a  domain  manager.  Additional 
responsibilities  are  to  provide  direction  to  program 
managers,  control  budgets  and  schedules,  and  set 
strategic  direction  for  the  evolution  and  use  of  the 
DSSA  environment.  The  domain  architect’s  role  is 
completely  incorporated  in  this  organization.  The 
domain  manager  also  enlists  the  aid  of  a  domain 
expert. 

Application  Developer.  An  application  developer 
may  be  a  contractor,  vendor,  or  government 
organization  that  develops  new  application  systems. 
This  organization  must  practice  a  software 
development  process  based  on  the  reference  model, 
reference  architecture,  and  library  components.  With 
the  help  of  a  domain  expert,  the  application  developer 
builds  target  systems  that  are  extensions,  tailoring,  or 
modifications  of  the  reference  requirements  and 
architecture. 

End  User.  An  end  user  is  an  organization  that  uses  the 
system  built  by  the  DSSA  process.  Although  the  end 
user  need  not  have  knowledge  of  the  DSSA 
development  environment  per  se,  he  or  she  provides 
important  information  as  to  the  content  of  domain 
knowledge,  new  and  changing  requirements, 
adequacy  of  documentation,  and  system 
effectiveness.  User  needs  are  dynamic;  static  systems 
become  obsolete.  Therefore,  a  domain  expert 
constantly  revises  his  or  her  domain  knowledge,  and 
end  users  are  a  key  input  to  this.  Not  only  applications 
but  reference  requirements  and  architectures  may 
need  to  reflect  the  end  user  inputs. 

Library  Center.  The  library  center  is  an  organization 
responsible  for  acquiring  and  maintaining  the 
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domain-specific  components  and  managing  the 
library.  The  library  center  may  be  in  the  direct  control 
of  the  domain  manager  organization  or  it  may  be  an 
independent,  external  organization  (for  example,  a 
STARS  or  CIM  library).  The  task  of  this  organization 
is  to  provide  access  to  an  organized  collection  of 
reusable  software  components.  It  classifies  and 
installs  components,  performs  configuration 
management,  and  collects  usage  metrics.  It  develops 
strategics  for  component  acquisition  and  provides 
user  services.  The  library  center  also  coordinates 
maintenance  and  enhancement  of  components, 
whether  in  response  to  specific  application  needs  or  to 
reflect  revisions  in  reference  requirements  and 
architecture. 

Maintenance  Center.  A  maintenance  center  is  an 
vganization  that  changes  and  improves  fielded 
'terns.  For  example,  a  Post  Deployment  Support 
enter  (PDSS)  is  a  maintenance  center.  The  DSSA 


approach  increases  the  operational  complexity  of  this 
type  of  organization.  Components  requiring 
maintenance  may  not  “belong”  to  the  center,  but  may 
come  from  a  reuse  library.  Furthermore,  necessary 
changes  to  reference  models  and  architectures  may  be 
identified.  Accounting  for  the  possible  ripple  effect  of 
any  particular  change  to  the  family  of  systems 
requires  analysis.  Areas  of  requirements  traceability, 
testing,  and  redesign  may  not  follow  traditional 
procedures.  Maintenance  is  an  important 
consideration  in  the  design  of  the  DSSA  process  and 
development  environment. 

The  DSSA  Process 

We  have  developed  a  detailed  IDEFO  model  of  the 
DSSA  process.  The  top  level  diagram  of  that  model 
(Figure  3)  identifies  the  major  four  phases  of  the 
DSSA  life  cycle.  A  description  of  each  phase,  with  its 
major  process  steps,  follows. 


Figure  3.  The  DSSA  Process — Top  Level 


11th  Annual  National  Conference  on  Ada  Technolozv  1993 


Establish  Domain-Specific  Base 

This  is  the  set  of  activities  performed  by  the  domain 
owner  >,  establish  a  DSSA  capability  base  for  the 
domain,  fhe  domain  is  analyzed  and  a  domain-specific 
software  architecture  (reference  architecture)  and 
development  environment  are  provided.  Specific 
activities  are: 

Model  Multiple  Views.  Multiple  views  of  the  domain 
are  provided  by  domain  experts  to  ensure  that  the 
broadest  range  of  intrinsic  concepts  is  addressed  These 
multiple  views  may  reflect  different  types  of  systems 
within  the  domain  (for  example,  strategic  vs.  tactical 
C2  systems),  or  may  reflect  different  perspectives  on 
the  domain  (for  example,  that  of  the  soldier  in  the  field 
vs.  that  of  the  strategic  planner).  These  views  are 
expressed  in  a  set  of  domain  models,  developed  using  a 
multiparadigm  combination  of  object-oriented, 
dynamic,  and  functional  descriptions. 

Establish  Consensus  Model.  A  consensus  of  the 
generic  domain  requirements  is  developed  to  build  a 
reference  requirements  model,  identifying  the 
functional  and  performance  characteristics  of  the 
family  of  systems.  This  is  a  model  of  the  reference 
requirements  that  will  be  the  foundation  for  a  family  of 
DSSA  systems:  it  is  one  of  the  key  DSSA  products, 
playing  a  key  role  in  application  development.  This 
activity  also  establishes  common  terminology  to 
describe  elements  of  the  domain.  Such  consensus 
building  will  draw  on  the  multiple  view  models,  but 
will  also  employ  workshops  or  similar  interactions  to 
help  build  agreement. 

Allocate  Requirements  to  Reference  Architecture.  The 
reference  requirements  are  allocated  to  architectural 
elements  (i.e.,  system  objects — software  or  hardware) 
to  create  a  reference  architecture  for  the  domain.  The 
reference  architecture  identifies  objects,  their 
interfaces,  and  their  topology.  It  serves  as  a  basis  for 
design  of  specific  systems  in  the  domain.  The 
architecture  will  continually  evolve  as  new  needs  arise 
from  various  sources  such  as  the  application  developer 
or  the  maintenance  center. 

Specify  Reusable  Component  Classes.  The 
architecture  defines  classes  of  software  objects  (for 
example,  forms  manager,  message  handler)  that  can  be 
used  to  build  applications  following  the  architecture. 
Multiple  components  can  be  provided  to  implement 
each  class,  varying  perhaps  in  functional,  performance, 
or  platform  particulars,  but  to  work  with  the 


architecture  each  must  conform  to  the  a  specification 
for  that  class.  The  specification  will  identify  all 
interfaces  and  behavioral  characteristics  on  which  the 
rest  of  the  architecture  depends. 

I&ilpr  Environm,gnlJQ_Po.TOip-  The  DSSA  process 
assumes  the  existence  of  a  DSSA  development 
environment,  i.e.,  a  set  of  tools  that  support  the  process 
steps  described  here.  The  base  toolset  is  domain 
independent — it  can  be  used  to  support  a  DSSA  process 
for  any  domain — but  several  of  the  tools  are  tailorable 
or  parametcrizablc  based  on  the  reference  requirements 
and  architecture.  This  step  creates  these  tailored 
instances  of  the  tools  for  the  domain  being  addressed. 

Populate  and  Maintain  Library 

This  is  the  set  of  activities  that  create  and  administer  the 
collection  of  reusable  components  that  implement  the 
DSSA.  Components  meeting  the  component  class 
specifications  in  the  reference  architecture  are 
collected,  modified,  and/or  developed.  Specific 
activities  are: 

Develop  Acquisition  Strategy.  The  domain  architect 
identifies  sources  that  will  provide  one  or  more 
components  meeting  the  component  class 
specifications.  An  acquisition  strategy  will  be 
developed  to  identify  components  and  acquire  them. 
Approaches  may  include: 

•  use  as-is  existing  components  1 

•  reengineer  existing  components 

•  build  an  application  generator 

•  develop  components  manually 

Provide  Components.  The  acquisition  strategy  is 
implemented  to  provide  components  conforming  to  the 
architecture.  If  problems  arise  in  doing  this — for 
example,  ambiguities  in  the  class  specifications — 
feedback  must  be  provided  to  the  domain  owner. 

Install  in  DSSA  Library.  Developed  components  are 
then  installed  in  the  library  supporting  the  domain. 
Depending  on  whether  the  library  is  “owned”  by  the 
domain  owner  or  is  an  independent  “public”  library, 
this  interface  may  differ.  If  a  public  library  is  used,  the 
domain  owner  must  be  proactive  in  ensuring  that 
needed  components  are  added  to  the  library  and 
continue  to  be  available,  at  the  same  time  conforming 
to  any  entrance  requirements  the  library  might  have.  It 
is  important  to  note  that  library  components  are  not 
necessarily  code;  typically  design,  documentation,  and 
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test  components  will  also  be  provided. 

Build  Applications 

This  is  the  set  of  activities  required  to  build  a  specific 
application  using  the  DSSA  library  and  the  domain- 
specific  development  environment.  Specific  activities 
are  defined  below.  (Note  that,  while  names  are  like 
those  in  the  traditional  waterfall  model,  activities  are 
quire  different.)  The  DSSA  environment  will  provide 
comprehensive  support  for  this  phase,  incorporating 
an  intelligent  decision  support  capability  that 
automates  each  activity,  additionally  providing  a 
requirements  traceability  mechanism  and  supporting 
prototyping,  evaluation  (metrics,  etc.)  and  testing. 

At  any  step  in  this  process,  any  deficiencies  or  needed 
improvements  in  the  reference  requirements, 
architecture,  or  components  arc  fed  back  to 
csponsible  organizations  (the  domain  owner  or  the 
hrary  manager). 

Develop  Requirements.  In  this  step  the  reference 
requirements  model  is  used  as  a  basis  for  stating  the 
requirements  for  the  specific  system  to  be  built  (the 
target  system).  The  target  system’s  requirements  are 
expressed  in  terms  of  the  reference  model,  for 
example: 

•  parameterized  requirements,  e.g., 
performance  measures,  arc  supplied  with 
target  system  values 

•  selections  among  alternative  capabilities  are 
made 

•  unneeded  capabilities  are  eliminated 

•  additional  detail  is  supplied  as  needed 

The  DSSA  tools  will  support  this  requirements 
elicitation  process,  interacting  with  the  designer  to 
create  the  target  system  requirements.  Rapid 
prototyping  can  easily  and  naturally  be  included  to 
help  clarify  requirement  distinctions. 

Design  Application  System.  The  reference 
architecture  is  then  instantiated  and  particularized  to 
establish  a  design  architecture  for  the  target  system. 
This  process  is  guided  by  the  mapping  from  the 
reference  requirements  to  the  target  system 
requirements,  and  in  fact  occurs  concurrently  with 
that  activity.  As  each  requirement  is  specialized  for 
the  target  system,  the  corresponding  element  of  the 


reference  architecture  is  adapted  to  become  a  part  of 
the  target  system  architecture.  Design  components  in 
the  DSSA  library  are  extracted  to  build  the  design. 

Implement  System. 

Creation  of  the  application  system  implementation 
(the  actual  code)  follows  naturally  and  automatically 
from  the  preceding  steps.  As  each  design  clement  is 
chosen,  a  corresponding  library  code  component  is 
identified.  Where  the  developer  must  provide 
adaptation  or  “glue”  software  to  connect  these 
components,  the  tools  identify  this  need  and  provide 
the  needed  interface  specifications.  If  the  toolset 
provides  a  component  generator  for  the  particular 
component  class,  the  developer  is  automatically 
guided  to  its  user  interface,  and  it  is  designed  to 
generate  only  components  that  conform  to  the 
architecture. 

Operate  and  Maintain  Applications 

Once  built,  the  application  system  is  operated  in  the 
field  and  maintained  by  the  maintenance  center. 
Specific  activities  arc: 

Carry  Out  Application.  The  application  system  is 
deployed  and  operated  in  the  field. 

Assess  Effectiveness.  As  part  of  its  normal  operation, 
the  effectiveness  of  the  system  is  assessed  against  the 
needs  of  its  continually  changing  mission.  Needed 
changes  and  corrections  are  identified  and  reported  to 
the  maintenance  center. 

Maintain  System.  The  maintenance  center  responds 
to  all  requests  from  users  for  changes  or  corrections  to 
the  system.  This  is  their  traditional  role;  however  the 
DSSA  approach  requires  a  much  different  approach  to 
system  maintenance  than  when  systems  are  built 
independently.  An  enhancement  or  correction  may 
affect  documentation,  system  requirements,  library 
components,  and  eventually  reference  requirements 
and  architecture.  Some  of  these  types  of  components 
may  not  be  under  maintenance  control  of  the 
maintenance  center.  For  example,  library 
components  may  be  maintained  by  the  library 
organization,  and  the  reference  requirements  and 
architecture  may  be  maintained  by  the  domain  owner. 
Further,  changes  to  these  entities  will  potentially 
impact  more  than  the  o.'e  application  system  that 
requested  the  change.  A  close  working  relationship 
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between  the  domain  owner  and  the  maintenance 
center  is  critical  to  the  success  of  this  activity. 


DSSA  promises  a  real  revolution  in  the  way  we  build 
software.  However,  as  this  brief  overview  indicates, 
the  DSSA  process  will  impact  significantly  the  roles 
and  responsibilities  of  all  organizations  involved  in 
the  creation  and  support  of  software.  This  creates  a 
challenge  to  the  industry  overall,  but  meeting  this 
challenge  must  start  with  the  DSSA  teams.  It  is 
essential  that  we  develop  a  process  that  is: 

•  clearly  defined  and  described 

•  comprchensi'  e — addresses  all  elements 
impacted  by  the  change 

•  practically  realizable  with  todav’s  resources 

•  supported  by  tools 

•  accepted  by  participants  in  the  process 

The  process  model  described  in  this  paper  (.and  in 
more  detail  in  the  referenced  materials)  is  a  beginning 
at  meeting  these  needs,  but  it  is  only  a  beginning.  The 
model  will  evolve  as  we  gain  experience  on  the 
project  as  the  first  practitioners  of  DSSA,  and  as  we 


explore  the  limits  of  what  is  possible  in  tooling  to 
support  the  process. 


The  work  described  in  this  paper  has  been  supported 
by  the  Defense  Advance  Research  Projects  Agency 
through  U.S.  Army  Communications-Electronics 
Command  Contract  No.  DAAB07-92-C-Q502. 
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Abstract:  Domain  Engineering  is  a  collection  of 
activities  (Domain  Identification,  Domain  Analysis, 
Domain  Design,  Domain  Implementation )  that 
provide  generic  requirements  and  designs  for  a  given 
domain  (family  of  systems  or  common  system  service). 
These,  in  turn,  are  tailorable  to  a  particular  system 
based  on  differing  factors  such  as  mission,  site, 
environment,  new  technology,  and  user  needs.  The 
products  ideally  contain  the  knowledge  base  of  the 
domain  and  include  reuse  guidance  incorporating 
rationale,  alternatives  discarded,  and  lessons  learned. 

Keywords:  Domain  analysis,  domain  design,  reuse, 
systematic,  opportunistic,  components,  object- 
oriented,  commonalities,  adaptation,  generic 
requirements,  generic  design,  DSSA,  and  generic 
architecture. 


1  INTRODUCTION 

Software  reuse  is  widely  recognized  by  industry  and 
government  alike  as  a  primary  mechanism  to  combat 
today's  software  crisis.  Many  experts  insist  that 
software  reuse  is  an  effective  means  to  increase 
software  development  and  maintenance  productivity, 
leads  to  greater  quality  and  more  reliable  software, 
and  can  preserve  software  engineering  expertise'. 
Although  increased  productivity  is  often  cited  as  a 
key  reason  to  practice  software  reuse,  the  most 
significant  benefits  may  come  from  increased 
reliability  and  lower  software  maintenance  costs. 
However,  even  with  the  potential  to  yield  higher-level 
software  productivity  gains  and  demonstrated  results 
of  several  reuse  case  studies,  there  still  remain  many 
barriers  to  reuse.  To  overcome  these  barriers  and 


maximize  benefits,  the  software  reuse  process  requires 
planning  and  methodical  integration  into  the  software 
development  life-cycle  (SDLC). 

Employing  a  domain  analysis  and  design  process  is 
one  of  several  existing  approaches  to  effectively 
identify  commonality  and  engineer  systems  for  reuse*. 
In  general,  domain  analysis  and  design  is  the 
systematic  exploration  of  related  software  systems  to 
discover  anr'  ploit  commonalities;  to  produce  a  set 
of  commo-  ipabilities,  processes  and  data  for  a 
"family"  ass  of  systems;  to  represent  and  model 
commonai.ues  in  a  usable  form;  and  to  provide  a 
method  to  map  commonality  to  specific  reuse 
instances.  The  primary  objectives  of  domain  analysis 
and  design  are  to  understand  the  domain,  to  support 
user-developer  communication,  to  provide  reuse 
requirements,  and  to  develop  products  that  support 
implementation  of  new  applications3.  By  applying 
domain  analysis  modeling  techniques  and  designing 
generic  architectures,  engineering  activities  focus 
primarily  on  developing  a  set  of  common 
requirements  and  exploiting  adaptable  architecture(s) 
for  a  "family"  of  systems  (hereafter  referred  to  as  a 
domain). 


1.1  .Typea  of  Software  Reuse 

Software  reuse  doesn’t  just  happen,  it  must  be 
integrated  into  the  SDLC.  Many  software  industry 
leaders  have  adopted  either  an  opportunistic  or  a 
systematic  approach  to  developing  reusable  software. 
Opportunistic  (sometimes  icfeTcd  to  as  ad  hoc)  reuse 
has  been  practiced  for  years  in  an  unstructured 
manner  by  those  sharing  code  modules.  The  potential 
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benefits  of  this  software  parts-bascd  approach  to 
software  engineering  are  significant,  but  they  are 
based  on  assumptions  that  a  given  domain  exhibits 
significant  commonality.  Commonalities  are  then 
exploited  through  the  development  and  application  of 
reusable  software  components  or  parts.  In  this 
approach,  reuse  benefits  are  achieved  only  at  the 
component  or  part  level. 

In  order  to  realize  greater  productivity  gains,  which 
are  needed  to  overcome  the  software  crisis,  a 
systematic  approach  to  reuse  is  most  useful.  This 
type  of  approach  is  formalized  at  more  than  an  ad 
hoc,  code-sharing  level.  Structured,  repeatable 
methods  are  employed  to  focus  on  emerging 
technological  software  engineering  activities,  such  as 
domain  analysis  and  design,  to  maximize  the  benefits 
of  reuse.  Domain  analysis  is  a  methodical  process,  or 
set  of  activities,  used  to  acquire  and  model  an 
understanding  of  the  domain  and  the  specifications 
common  to  systems  within  the  domain.  Domain 
design  activities  use  the  domain  model  and 
specifications  to  develop  generic  domain  designs  as 
configurable  or  adaptable  frameworks  for  constructing 
new  systems  in  the  domain.  Reusable  software 
components  that  implement  domain  specifications  are 
then  acquired  and/or  developed  for  next  generation 
system  development.  New  development  efforts  in  the 
domain  can  reuse  domain  specifications,  instantiate 
domain  design(s)  and  reuse  the  associated  lower-level 
implementation  components,  thus  realizing  far  greater 
benefits  of  reuse. 


12-Erahlem. Space  vs>.  Solution  Space 

The  domain  problem  space  is  the  set  of  requirements 
that  future  systems  in  the  domain  will  need.  The 
domain  solution  space  represents  the  implementation 
of  the  problem.  Successful  reuse  requires  the 
developer  to  match  a  current  set  of  problems  (system 
requirements)  to  previous  solutions.  The  design 
and/or  implementation  of  the  previous  requirement 
can  then  be  adapted  as  a  solution  to  the  current 
problem.  Domain  engineering  provides  a  systematic 
approach  that  concentrates  specifically  on  defining 
problems  and  producing  adaptable  solutions  in  a 
domain  in  order  to  increase  productivity  in  future 
system  development  activities5.  This  process,  which 
complements  and  facilitates  system  development,  is 
an  essential  part  of  an  effective,  reuse-based 
development  methodology. 


1.2.1  Problem  SPICI  In  traditional 
system  software  development,  problems  are 
formulated  and  defined  as  requirements  for  specific 
software  systems  (or  parts  of  systems).  Domain 
analysis  identifies  and  models  the  problem  space  for 
a  "family"  of  systems  (domain),  and  provides  reusable 
requirements  to  address  recurring  problems  in  the 
domain.  The  problem  space  defines  common 
capabilities  within  the  domain,  as  well  as  associated 
variations  and  combinations.  It  is  essential  to  define 
domain  capabilities  to  be  effective,  flexible  and 
remain  viable  over  changes  in  technology,  time, 
needs,  people  and  budget.  To  support  these  changes, 
problem  space  requirements,  must  be  adaptable  and 
understandable. 

Domain  models  are  developed  as  abstract 
representations  of  systems  existing  in  the  domain 
and/or  future  domain  requirements.  These  abstract 
domain  representations  serve  as  models  for 
constructing  future  systems.  The  interpretation  of 
domain  models  is  flexible  and  allows  alternative 
realizations  to  accomplish  different  needs. 

1.2.2  Solution  Space.  Domain  design 
focuses  on  the  solution  space  where  solutions  take  the 
form  of  design  and  other  artifacts  that  together 
constitute  a  framework  to  address  the  problems  in  the 
domain.  Domain  design  applies  system  problem 
solving  to  construct  a  generic,  adaptable  design  that 
satisfies  domain  requirements.  This  generic  design 
serves  as  the  basis  for  the  system  software  design 
activities.  During  system  software  design,  a  software 
architecture  that  exploits  the  implementation 
dependencies  of  the  target  environment  is  constructed. 

Domain  architectures  allow  the  developer  to  create 
robust  language-independentsolutionssatisfying  those 
requirements,  without  concern  for  how  the  software 
will  be  implemented.  This  preliminary,  logical 
design  is  the  developmental  bridge  between  the 
problem  domain  and  the  software  implementation  or 
solution  space.  The  resulting  problem  domain  and 
solution  space  mapping  is  essentia!  to  effectively 
maximize  the  benefits  of  software  reuse. 


1.2.3 _ Increased  Benefits.  There  is 

potentially  a  much  greater  return  on  investment  by 
employing  a  systematic  reuse-based  approach  and 
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applying  the  domain  analysis  and  generic  architecture 
design  techniques  described  in  this  paper.  For 
instance,  if  requirements  for  developing  a  new  system 
match  (to  a  certain  degree)  an  existing  domain  model, 
it  may  be  more  feasible  to  adapt  the  corresponding 
domain  design  and  reuse  large  portions  of  associated 
existing  system  components,  such  as  detailed 
design;.'  and  code. 

This  paper  presents  one  method  of  domain  modeling 
and  generic  architecture  design,  and  includes  essential 
activities  in  conducting  the  domain  analysis  and 
design  process  to  enable  software  reuse  and  maximize 
the  associated  ben  fits. 

2,0  DOMAIN  ENGINEERING  L1FE-CYCLE 

Domain  engineering  is  the  process  by  which  all 
domain  products  are  created.  The  four  major  activities 
of  domain  engineering  are: 


1.  Domain  Identification 

2.  Domain  Analysis 

3.  Domain  Design 

4.  Domain  Implementation* 

As  in  standard  software  development,  various  life- 
cycles  are  possible,  from  waterfall  to  spiral  to 
incremental. 

The  products  of  domain  engineering  relate  to  the 
application  life-cycle  as  shown  in  Figure  1.  The 
domain  models,  from  which  the  generic  requirements 
are  generated,  are  composed  of  graphical 
representations  and  object  specifications.  The 
architectures  are  composed  of  generic  designs. 
After  completion,  the  domain  products  are  placed  in 
reuse  repositories  for  accessibilitv. 


Figure  1.  Integration  o!  Domain  Engineering  and  Application  Engineering  Life-Cycles. 

Domain  implementation  is  basically  the  application  of  well-known  coding  and/or  re-engineering  principles  and. 
therefore,  will  not  be  covered  within  this  paper. 
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As  in  the  practice  of  standard  software  analysis  and 
design,  several  domain  analysis  methods  exist  at  the 
present  time.  In  order  to  classify  and  combine 
common  system/software  capabilities,  the  method 
presented  in  this  paper  is  a  completely  object-oriented 
approach.  This  approach  was  adopted  for  several 
reasons: 

1.  Object-oriented  methods  provide  inherent 
constructs  for  identifying  commonality 
(classes),  variability  (subclasses)  and 
cardinality  (instance  connections). 

2.  Traceability  is  established  on  an  object 
basis  from  requirements  through  code. 
Every  object  in  the  requirements  phase  has 
one  or  more  objects  in  the  design  and 
implementation  phase. 


4.  During  the  construction  of  an  object,  both 
during  analysis  and  design,  changes  within 
an  object  will  have  little  or  no  ripple 
effect  in  other  objects,  allowing  the 
information  clustering  to  proceed  without 
extensive  revisiting  of  related  objer's. 

Although  many  existing  systems  have  been  developed 
with  functional  or  hybrid  methods,  the  information 
clustering  necessary  to  identify  commonality  requires 
a  complete  information  restructuring. 

The  specific  graphical  techniques  currently  employed 
in.  this  process  are  Coad/Yourdon  analysis  notation9 
and  Buhr  '90  design  notation*.  Several  other  analysis 
and  design  notations  are  presently  being  considered 


in  light  of  emerging  domain  engineering  needs. 

The  detailed  examples  provided  herein  to  demonstrate 
concepts  were  derived  from:  1)  The  U.S.  Army 
Reuse  Center  (Software  Development  Center  - 
Washington)  P’ogram  Executive  Office  -  Standard 
Army  Management  Information  Systems  (PEO- 
STAMIS)  retail  supply  domain  analysis  effort:  2) 
information  from  other  supply  systems 
documentation;  and  3)  ongoing  method 
enhancements.  For  this  paper,  the  information  has 
been  greatly  simplified  for  purposes  of  demonstration 
and  should  therefore  be  considered  in  the  light  of 
concept  communication  only. 


2.2  Domain  Identification 

Before  an  analysis  of  a  domain  can  begin,  a  domain 
must  be  defined.  The  first  consideration  in  domain 
definition  is  the  orientation  of  the  domain  in 
question.  The  domain  orientation  is  either  vertical  or 
horizontal.  If  the  reuse  projected  involves  a  family 
of  related  systems,  it  is  said  to  be  a  vertical  domain13. 
If  the  reuse  projected  involves  a  segment  of  many 
families  of  systems,  it  is  said  to  be  a  horizontal 
domain  (see  Figure  2).  A  mission-specific  domain 
(e.g.,  Radar-Guided  Missiles  or  Logistics)  tends  to  be 
vertical  and  a  system  support  domain  (e.g.,  COTS 
bindings,  GUIs,  Communications,  or  Data  Base 
interfaces)  tends  to  be  horizontal. 

In  order  to  understand  the  extent  of  the  domain 
engineering  effort,  the  boundary  must  be  established. 
The  boundary  identifies  the  characteristics  that  are 
used  to  classify  systems  as  part  of  a  specific  domain. 
As  a  high-level  example,  the  Patriot  Missile  System 
belongs  to  a  Radar  Guided  Missile  domain  and  the 
Sidewinder  (infra-red  guided)  does  not. 


Example: 

Under  the  PEO-STAMIS  domain  analysis  effort, 
approximately  26  systems  were  identified  as 
candidate  PEO-STAMIS  systems.  During  this  effo't, 
the  fundamental  capabilities  of  these  systems  were 
assessed  to  identify  similarities.  Organizational 
entities  were  examined  to  identify  responsibilities. 
The  results  in  Figure  3  portray  the  domain 
organization  of  PEO-STAMIS.  The  Supply  domain 
was  chosen  from  the  domains  in  PEO-STAMIS  in 


3.  The  transition  from  object-oriented 
analysis  (OOA)  to  object-oriented  design 
is  greatly  simplified.  "Because  of  th* 
difference  in  aggregation  principles, 
proceeding  from  a  structured  analysis  to 
an  object-oriented  design  can  be  awkward. 
Since  the  criteria  for  grouping  functions 
are  different  in  the  two  methods,  the 
transition  from  one  to  the  other  may 
require  significant  recasting  of  the  data 
flow  diagrams.  This  is  a  laborious  process, 
which  can  be  avoided  by  assuming  an 
object-oriented  viewpoint  during  the 
analysis  phase".4 
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Figurt  2.  Domain  Orientation  (Horizontal  va.  Vartlcal) 


order  to  utilize  the  wealth  of  available  information 
and  to  latirfy  the  need*  of  upcoming  Supply  ay  stems. 

The  reuse  potential  discovered  included  both 
horizontal  and  vertical  reuse.  For  the  sake  of  brevity, 
thii  paper  will  focus  on  vertical  reuse.  The 
boundaries  of  the  domain  analysis  were  drawn  around 
the  aystems  that  had  supply  responsibilities  (see 
Figure  J). 

In  general,  the  PEO-STAMIS  Supply  Domain  consists 
of  logistics  systems  that  provide  the  fundamental 
capability  to  supply  customers  with  the  assets 
required  to  accomplish  their  respective  missions 
Customers  and  customer  needs  may  vary  at  different 
echelon  level*  within  the  Army's  organizational 
structure.  For  ayatems  at  the  brigade,  battalion, 
company  echelon,  for  eaample,  the  customers  may  he 
tactical  commanders  Whereas,  customers  at  the 
theater,  corps  and  division  echelons  msy  he  mo*or 
pool  mechanic*  or  intermediate  supply  points, 


2JJDQmiin.An*]yiii 

The  objective  of  domain  analysis  is  to  identify, 
derive,  organize,  abstract,  and  represent  the  body  of 
knowledge  of  a  particular  domain*  This  body  of 
knowledge  is  represented  by  a  domain  mode/.  $ 
model  similar  to  an  Object ‘Oriented  requirements 
Analysis  ((X)A).  Tire  difference  between  a  domain 
model  and  an  OOA  are  the  additions  in  the  domain 
model  of  reuse  guidance  in  the  form  of  adept  at  irm 
requirements,  altemativrsdiscarded.  rsimnale  lessons 
learned,  and  identification  of  aystems  supplying  or 
consuming  the  domain  privlucts  This  information  s 
the  key  to  providing  the  estis  information  needed  to 
construct  requirement*  for  many  Tutor#  *y  stem*  The 
domain  model  provides  input  to  hoth  the  domain 
designer  and  the  applltation  an f) ware  analyst 


1 

B 


I 


PEO-STAMIS 


Medical 

T  AMMIS 


Logistics 


Personnel 

[-siDPtes  J 


Maintenance 


SAMS  t 
SAMS  } 
SAMS  ] 
SAMS  I 10A 


;%%  it  isi 


SAAS  I  1 
SAAS  4 

SAAS  0 AO 
SAMSS  1 
sauss ;a 
sahss ;n 


sns  moo 
sees  r 

SPSS M  I  TDA 

U1  ss  Ci 

UllSA 

ui  ss  r»4 


i 


Transportation 

DAMMS  MPM 

0AMM5  HI 
OAMMS R2 


SB»r>  and  ISM  belong  to 
multiple  dornam* 


r-igure  3.  PEO-STAMIS  Supply  Domain  Boundaries. 


i 


i 


i 


Different  domain  analysis  method*  vary  in  their  goals 
as  to  the  depth  of  information  to  model,  lor 
(■sample,  the  Software  Engineering  Institute  s  Feature 
Oriented  Domain  Analysis  (F'ODA)  aims  at  capturing 
user-visible  aspects  of  the  problem  space  as  a  means 
of  identifying  u«er  requirements  Additionally,  other 
methods  include  all  of  the  problem  space  aspects  in 
the  domain  model  as  means  of  "disseminating 
knowledge  among  engineers  as  a  way  of  improving 
the  development  process".  ” 

"Die  primary  steps  of  domain  analysis  are: 

1  Information  Gathering  and  Organization. 

2  Commonality  Identification. 

1  Adaptation  Identification,  and 

4  ISomain  Model  Verifii  alion 

These  steps  i  an  tw>  performed  in  sequent  f .  although 
ctjieneme  has  shown  that  iterations  can  produce 
greater  detail  and  understanding  thereby  uu  teasing 
reuse  potential  Information  gmhenng  lends  to 
t  detinue  into  t  nnimnnatily  identification.  as  some 
dot  nmerils  may  tefereme  other  publn  alum*  needeil 
or  helpful  to  the  analysts  effort  The  uh mdu  anon  of 


ndaplatton  requirements  often  lakes  place  etch  time 
a  commonality  is  discovered, 
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Organization.  During  this  step,  the  domain  jiijUms 
acquire  information,  at  a  minimum,  in  the  form  of 
system  documents,  planning/concept  documents  and 
initial  domain  espert  interviews.  Tins  information 
becomes  the  basis  for  a  working  domain  knowledge 
base.  This  knowledge  base  will  be  used  throughout 
the  domain  analysis  and  design  activities  before  the 
completed  product*  are  formally  certified  and 
installed  in  the  reuse  repository.  Ideally,  all 
significant  information  will  be  included  in  the 
certified  domain  product*.  The  type*  of  information 
to  focus  on  ate  tho*e  that  will  have  some  impact  on 
future  systems  Obsolete  or  out-dated  information  is 
not  maintained  in  the  domain  model,  although 
knowledge  of  the  amount  and  rate  of  obsolescence 
can  help  determine  the  stability  of  a  domain 

The  knowledge  base  need*  an  organizational 
Mnidurf,  Rapid  access  to  particular  groupings  of 
domain  information  require*  *n  indesing  ot  the 
information  according  to  the  type  of  information 
acquired  (eg,  *y»irm  document  v*  interview, 
obsolete  v»  future  need). 


2.3.2  Commonality  Identification  In 

order  to  establish  a  basis  for  commonality 
identification,  an  entity-relationship  model  is 
constructed  (unless  one  is  available  from  a  business 
improvement  initiative  effort).  Commonality 
identification  determines,  to  a  large  part,  the  amount 
of  reuse  potential  to  be  realized  from  the  domain 
engineering  effort.  The  common  information  can  be 
in  the  form  of  objects,  classes,  functions,  processes, 
entities,  relationships,  data  elements,  and  so  forth. 
What  is  searched  for  is  not  necessarily  exact  matches, 
but  similarities.  Commonality  can' be  identified  in  a 
number  of  ways: 

1.  Identification  by  Domain  Experts  -.Such 
as  system  users,  functional  proponents, 
commanders,  and  other  related  individuals 
that  have  had  to  work  with  and  understand 
the  problem  domain  in  question.  Their 
knowledge  of  repeated  processes  and  data 
manipulation  algorithms  is  extremely 
valuable.  Different  types  and  levels  (i.c., 
skill  area,  rank)  of  domain  experts  have 
different  perspectives  that  allow  multiple 
perspectives  of  commonality. 

2.  Examination  of  Analysis  Documentation  • 
All  information  in  the  form  of  software 
engineering  data,  such  as  object  diagrams 
(interaction,  inheritance,  aggregation,  etc), 
data  flow  diagrams,  state  transition 
diagrams,  and  data  models,  are  necessary 
sources  for  the  modeling  of  the 
requirements  of  the  domain.  As  discussed 
in  CAMP  3",  software  components  can 
exist  at  different  levels  of  abstraction.  We 
may  find  similarities  at  the  smallest 
component  level,  at  a  Computer  Software 
Component  (CSC)  level,  or  at  an 
architectural  level.  Often,  the  sane 
information  is  represented  with  different 
formats,  terminology,  and  in  different 
groupings. 

3.  Examination  of  Design  Documentation  - 
Design  documentation  portraying  previous 
«y  stein  solutions  can  provide  commonality 
intormation  through  the  study  of  the  use 
of  generics,  templates,  and  other  reuse 
mechanisms  Often,  a  system's  analysis 
products  are  in  a  functional  decomposition 


format.  If  the  corresponding  design 
employed  OOD  methods,  identification  of 
problem  space  objects  in  the  design  can 
also  be  useful  to  the  domain  analysis 
process.  This  constitutes  a  reverse 
engineering  of  the  design.  The  analyst 
must,  however,  be  alert  to  avoid 
introducing  solution  space  information 
into  the  problem  space  and  remain  focused 
on  only  the  problem  space  objects  found 
in  the  design. 

As  in  object-oriented  analysis,  commonalities  arc 
generalized  into  classes  that  represent  abstractions  of 
their  respective  set  of  objects.  This  process  is  not 
strictly  top-down  (i.e,  without  regard  for  existing 
assets)  in  nature,  nor  is  it  purely  bottom-up  (ie„ 
basing  analysis  only  on  existing  assets).  The  goal  is 
to  satisfy  future  requirements  with  as  many  existing 
assets  as  practicable. 

The  commonality  identification  progression  does  not 
just  proceed  from  the  high  level  of  abstraction  to  the 
lowest.  Instead,  there  is  a  sinusoidal  "porpoising" 
effect  as  new  information  discovered  in  the  lower 
levels  of  detail  affect  parent  classes/objects.  There  is 
an  iterative  shaping  of  the  classes  as  new  similarities 
arc  discovered. 


Adaptation  requirements  identify  the  different 
application  of  the  common  capabilities.  Just  as 
commonality  identification  is  necessary  to  establish  a 
grounds  for  reuse,  adaptation  identification  is 
necessary  to  tailor  the  information  to  particular  needs. 
Some  adaptation  factors'*  arc:  i 


1.  Flexibility  in  operation. 

2.  Mission  adaption  (needs,  threats,  etc.). 

3.  Environment/site  adaptation.  ^ 

4.  Platform  adaptation, 

3,  User  adaptation,  and 

6.  New  technology  adaptation. 


These  factors  can  be  identified  concurrently  with  the 
commonality  identification. 
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The  techniques  in  representing  adaptation  can  tike 
many  forms.  The  generalisation-specialisation  feature 
of  OOA  provides  for  subclasses  where  different 
co»vfigurations  can  be  further  represented.  The  object 
specifications  have  adaptation  sections  in  the  class/ 
object,  attribute,  and  operation  sections.  State 
transition  and/or  structured  logic  representations  can 
alao  identify  tailorable  needs  by  modified  notation. 

Often,  another  perspective  on  commonality  may  be 
realized  in  this  step,  causing  a  refinement  to  a  class 
content  or  hierarchy. 

In  some  cases,  certain  capabilities  may  be  mutually 
exclusive  and  cannot  exist  together  in  the  same 
system.  This  cardinality  can  be  represented  by  an 
instance  connection  that  denotes  a  zero-to-zero 
relationship  between  objects/classes. 

Exam  pi*: 

The  external  interfaces  to  the  supply  domain  are 
generalized,  as  shown  in  Figure  4. 

The  supply  domain  has  several  common 
characteristics  in  the  form  of  attributes  (data)  and 
operations  (functions).  Each  system  in  the  PEO- 
STAMIS  domain  (or  nearly  all)  possessed  all  of  the 
capabilities  listed  in  Table  I. 

Next,  patterns  of  variations  of  those  capabilities  were 
sought  to  identify  adaptation  requirements.  Some  of 
the  differences  were  attributed  to  the  unique 
requirements  in  the  handling  of  different  supply 
classes  (bullets  versus  bread,  for  example).  Others 
were  identified  by  organizational  needs  (in  this  case, 
Army  echelons).  For  example,  commanders  at  the 
theater  level  need  visibility  and  modifiability  of  the 
distribution  of  stock  to  the  fielded  divisions,  whereas 
unit  commanders  only  need  information  concerning 
their  own  company  inventory. 

These  groupings  led  to  the  formation  of  subclasses 
representing  the  variations  in  system  responsibilities 
(see  Figure  5). 


2.3.4  Domain  Model  Verification  The 
domain  model  must  be  verified  in  order  to  establish 
a  reliable  baseline.  The  business  process  and  data 
models,  if  available,  should  be  used  as  the  "doctrine" 


against  an  operational  scenario.  Verification  ctn  be 
accomplished  in  the  following  ways: 

1.  Inspection  •  A  team  of  domain  experts 
examines  the  model  to  verify 
completeness  and  correctness. 
Preferably,  at  least  some  of  the  domain 
expens  will  not  have  taken  pan  in  the 
information  gathering,  therefore, 
providing  an  independent  review. 
Operational  scenarios  can  be  used  at 
this  step  to  assure  the  correctness  of  the 
model. 

2.  Prototyping  -  A  small  set  of  capabilities 
can  be  implemented  using  a  prototyping 
tool/language.  The  prototype  would 
then  be  executed. 

3.  Simulation  -  A  simulation  model  can  be 
constructed  to  determine  (to  a  factor  of 
confidence)  the  viability  of  the 
allocation  of  performance  requirements. 

2.4  Design  Domain 

The  goal  of  domain  design  is  to  produce  a  Domain 
Specific  Software  Architecture  (DSSA)  with  reuse 
guidelines  and  classification.  A  DSSA  is  "based  on 
the  concept  of  an  accept"*  generic  architecture  for  the 
target  domain.  As  defined  by  DSSA,  a  software 
architecture  describes  the  topology  of  software 
components,  specifies  the  component  interfaces,  and 
identifies  computational  models  associated  with  those 
components."'  Quanrud  has  stated,  "A  generic 
architecture  provides  a  high  level  design  for  a  family 
of  related  applications  and  a  set  of  reusable 
components  that  are  specifically  intended  for  use  in 
those  applications.  The  reusable  components  are 
designed  to  work  together  and  should  provide  most  of 
the  code  that  would  be  included  in  a  typical 
application.  Actual  applications  are  developed  by 
adding  application  specific  components  and  adapting 
the  reusable  components  to  meet  the  requirements  of 
the  application.  Adaptation  of  a  reusable  component 
may  take  the  form  of  modification,  extension,  usc-as- 
ia,  or  replacement.”  prescribe  a  specific  completion 
point  for  the  DSSA,  but  provides  for  the  tailoring  of 
the  level  12. 

The  level  of  detail  in  a  DSSA,  at  the  time  of  this 
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Figure  4.  Supply  System  External  Interfaces 


Table  I.  Common  Supply  Operations  and  Attributes  (Example) 


ATTRIBUTES 

Transactions 
Stock  Quantities 
Catalog 

OPERATIONS 

Accept  Incoming  Request  (for  Stock) 
Request  Transaction  Receipt/Status 
Provide  Transaction  Receipt/Status 
' Cancel /Modify  Incoming  Request 
Issue  Stock 
Receive  Stock 
Perform  Inventory 
Maintain  Stockage  Levels 
Receive/Update  Catalog 
Disseminate  Catalog 


Figure  5.  Variations  Depicted  as  Subclasses 


writing,  has  been  nominally  equivalent  to  a  hi<-h-Ievel 
design,  "fhis  DISA/CIM  Domain  Ana'.  <  and 
Design  Prcicess  does  notof  detail  by  pro»  -nrv  a 
completion  criteria  control  to  be  determin'd  by 
management. 


The  purpose  of  the  DSSA  is  to  provide  a  framework 
illustrating  the  major  components  and  their  interfaces 
that  satisfy  the  requirements  of  the  domain  model, 
from  commonality  to  adaptation.  This  includes  reuse 
guidelines,  rationale,  and  discarded  alternatives,  in 
order  to  give  the  software  designer  an  understanding 
of  the  avenues  already  explored.  The  reuse 
guidelines  help  the  system  designer  understand  the 
assembly  and  tailoring  of  an  application  from  a 
DSSA. 


As  in  standard  software  design,  the  qualities  of 
reusability,  adaptability,  and  efficiency  must  be 
balanced  to  meet  the  demands  of  the  domain  under 
development.  For  example,  in  a  "hard"  real-time 


environment,  some  aspects  of  reusability  and 
tailorability  may  have  to  take  secondary  consideration 
to  efficiency  in  order  to  meet  performance 
requirements11.  Other  domains,  especially 
Management  Information  Systems  (MIS),  can  realize 
the  cost-saving  benefits  of  more  thorough  abstraction, 
encapsulation,  and  parameterization  due  to  less 
stringent  timing  and  sizing  constraints. 

The  domain  design  process  is  outlined  in  the 
following  major  steps: 

1.  Identify  Domain  Constraints, 

2.  Collect  and  Organize  Design  Information. 

3.  Identify  Potential  Design  Components, 

4.  Develop  Architecture,  and 


5.  Validate  Architecture. 
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The  domain  design  process  can  be  top-down  only, 
bottom-up  only,  or  a  combination  of  the  two.  The 
third  alternative  will  be  presented  herein,  although 
optional  processes  can  be  deleted  to  enable  top-down 
only. 

2.4.1  Identify  Domain  Constraints.  The 
goal  of  this  process  is  to  identify  all  established  and 
potential  constraints  affecting  the  design  process.  A 
number  of  factors,  such  as  imposed  standards, 
Commercial-Off-The-Shelf  Software  (COTS). 
Govemment-Off-Thc-Shelf  Software  (GOTS),  and 
hardware,  can  limit  the  choices  a  domain  designer 
can  make.  A  successful  domain  design  meets  as 
many  constraints  as  is  practicable,  thereby  enabling 
reuse. 

The  domain  designer  identifies  constraining  standards, 
policies,  directives,  guidelines,  and  any  other 
documents  that  impose  design  guidance  on  the 
domain  design.  These  include  decisions  as  to 
environments.  COTS/GOTS  assets,  data 
standardization,  and  other  aspects. 

The  domain  designer  researches  preplanned  hardware 
constraints  to  determine  if  the  design: 

1.  Must  be  tailored  to  meet  specific  goals 
dictated  by  timing,  sizing  requirements, 
or 

2.  Will  be  released  from  previously 
established  constraints. 

The  domain  d 'signer  identifies  the  domain  system 
boundaries  as  directed  by  management,  that  is,  the 
interfaces  to  other  layers/compon'nts  in  the  system. 
For  example,  management  guidance  might  dictate  that 
a  communications  domain  be  implemented  without 
regard  to  any  particular  mission-specific  domain. 


2.4.2  Collect  and  Organize  Design 

information.  The  domain  designer  creates  a 
catalogue  of  existing  design  solutions,  domain 
constraints,  and  lessons  learned.  The  catalog  is 
needed  to  provide  an  index  for  efficiently  accessing 
pertinent  design  information  without  requiring  sifting 
through  stacks  of  documents  or  hundreds  of  files. 

Existing  design  information  takes  many  forms.  Some 
projects  have  complete  and  up-to-date  design 


documents,  while  other  projects  choose  not  to 
maintain  or  keep  their  documents.  A  potential  source 
of  design  information  can  be  acquired  by  reverse¬ 
engineering  code,  though  the  algorithmic  information 
is  usually  difficult  to  obtain.  Other  sources  include 
repositories,  trade  journals  and  publications,  text 
books,  and  academic  publications. 


2A3 _ tdanillx _ Eolgnlial .  Design 

Components.  This  crucial  step  enables 
construction  of  an  architecture,  which  is  the  next  step, 
by  identifying  existing  quality  design  components. 
This  takes  place  before  the  actual  start  of  architectural 
construction  so  that  available  components  arc  used  as 
the  basis  for  the  design.  In  the  past,  designers  would 
often  develop  a  design,  then  look,  often 
unsuccessfully,  for  components  that  fit  the  design. 
NOTE:  This  step  is  optional  if  the  domain 
engineering  effort  is  top-down  only. 

Domain  designers  and  implementors  identify 
components  meeting,  at  least  partially,  the 
requirements  of  the  domain  model.  This  provides  for 
reusability  of  existing  components  by  using  them  to 
define  the  design.  Ideally,  the  components  have  been 
developed  using  similar  domain  analysis  method 
paradigms  to  enable  an  uncomplicated  comparison 
task.  For  example,  if  the  components  were  developed 
using  object-oriented  design  and  the  domain  analysis 
method  is  object-oriented,  then  the  information 
restructuring  effort  will  be  minimal.  If  the  domain 
analysis  method  is  functional  in  nature,  considerable 
effort  will  be  required  to  convert  one  information  set 
into  the  representation  of  the  other. 

The  engineers  assess  the  reusability  by  applying 
established  reusability  criteria.  This  helps  to  filter  out 
components  that  will  have  little  or  no  value  in  this 
effort,  and  to  focus  on  the  most  promising  ones.  A 
number  of  metrics  are  captured  and  the  amount  of  re¬ 
engineering  is  estimated.  Based  on  these  results  and 
their  comparison  to  the  reuse  criteria,  a  determination 
is  made  to  either  accept  the  component  as  a  potential 
candidate,  to  reject  the  component,  or  to  decompose 
the  component  to  allow  a  more  complete  assessment. 


Z&A _ Develop  Architecture,  This 

process  utilizes  components  identified  in  the  previous 
activity  to  construct  the  DSSA.  Often,  several 
alternatives  can  be  derived  from  existing  systems  that 
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satisfy  the  requirements  and  constraints.  If 
appropriate,  one  DSSA  should  be  selected  that 
provides  the  best  solution.  In  very  large  domains, 
one  overall  DSSA  may  not  provide  enough 
commonality  to  be  of  substantial  use.  If  for  some 
reason,  existing  architectures  are  not  used/available, 
then  the  standard  software  design  principles  are  used 
to  create  the  DSSA  from  the  domain  model,  within 
the  identified  domain  constraints.  Care  must  be  taken 
to  adhere  strongly  to  the  software  engineering  rule  of 
abstracting  detail  to  the  lowest  level  and  isolating 
implementation  dependencies. 

This  process  produces  a  design  specification 
providing  enough  information  to  advance  to  the  next 
level  of  design.  Criteria  established  at  the  beginning 
of  the  effort  determines  the  level  of  detail  to  be 
achieved.  Until  the  required  detail  is  reached,  the 
design  is  continually  decomposed  and  refined. 

As  in  the  domain  model,  reuse  guidance  is  provided 
to  help  the  system  developer  tailor  the  design  to  the 
specific  needs  of  the  system  under  development.  The 
domain  designer  creates  a  set  of  guidelines  for  using 
the  DSSA  in  a  full  scale  software  development 
activity.  These  include  a  discussion  of  the  rational 
for  the  selection  of  a  particular  alternative,  when  to 
use  particular  components,  how/where  these 
components  have  been  used  previously,  and  any 
lessons  learned. 


2.4.5  Validate  Architecture.  To  ensure 
the  DSSA  created  meets  the  domain  model 
requirements,  domain  constraints,  and  provides  a 
workable  solution,  the  domain  designers  and 
implementors  must  validate  the  DSSA.  To  do  this, 
alternative  approaches  exist: 

1.  Inspection  -  Domain  technical  experts 
review  the  architecture  and  provide 
input  regarding  the  correctness,  from 
their  perspective. 

2.  Simulation  -  The  software  characteristics 
are  used  to  produce  a  simulation  model 
focusing  on  measurable  performance. 

3.  Prototype  -  A  small  demonstration 
program  is  assembled  to  ensure  that  the 
design  can  be  successfully  instantiated 
by  an  application.  Further  lessons 


learned  and  reuse  guidance  are  captured 
in  this  phase. 

Exempt* 

This  example  demonstrates  the  construction  of  a 
mission-specific  (supply)  DSSA.  The  data  and 
operations  listed  in  Table  1  were  grouped  together 
into  distinct  objects  by  a  closer  examination  of  their 
content  and  purpose.  In  order  to  manage  complexity, 
the  construction  of  the  DSSA  proceeded  by: 

1.  Object  identification, 

2.  Object  interaction,  and 

3.  Object  structure  identification. 

The  first  two  steps  are  illustrated  by  an  abstract 
structure  chart  (sec  Figure  5).  The  third  step  is 
illustrated  with  a  concrete  structure  chart  (sec  Figure 
6). 


Object  Identification  -  The  first  data  item 
(TRANSACTION)  and  the  first  four  operations  center 
around  the  management  of  transaction  information  (a 
REQUEST  is  one  form  of  a  transaction).  This 
suggests  an  elaboration  of  an  abstract  object 
'TRANSACTION"  as  shown  in  Figure  5.  The  next 
data  item  and  the  next  four  operations  focus  on 
management  of  the  'nventory.  and  can  establish  an 
abstract  object  ”L  VENTORY”.  Finally,  the 
remaining  data  item  and  operations  manipulate  the 
catalog  information  used  to  order  stock  from  the 
supplier.  These  are  grouped  to  form  the  abstract 
object  "CATALOG  ". 

Object  Interaction  -  The  establishment  of  the 
interfaces  with  the  external  entities  (the  customer  and 
the  supplier)  reveal  that  the  only  two  "visible"  objects 
are  "TRANSACTION"  and  "CATALOG".  The 
"INVENTORY"  object  receives  commands  only  after 
the  initial  transactions  are  validated,  and  generates  an 
event  to  create  a  transaction  if  stock  levels  drop 
below  a  preset  point.  This  interface  organization 
allows  for  an  orderly  control  of  the  inventory  and 
separates  the  processing  of  two  types  of  data 
(inventory  and  transaction).  The  CATALOG  object 
does  not  need  to  interface  to  the  other  objects  as  it  is 
only  accessed  to  update  the  catalog  and  to  order 
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shipments  of  stock. 

Object  Structure  Identification  -  At  this  stage, 
the  details  of  the  objects,  are  identified  to  provide  a 
complete  design  descriptirn.  The  operations  and  data 
that  where  grouped  before  to  identify  objects  are  now 
represented  along  with  any  structural  decomposition. 
For  example.  Figure  6  shows  the  structure  of  the 
three  objects  that  include  the  operations  and  data 
from  the  domain  model.  The  INVENTORY  object 
not  only  has  the  Issue  Stock,  Receive  Slock,  and 
Perform  Inventory  operations,  but  also  a  Check 
Stock  Quantities  operation  needed  by 
TRANSACTIONS  to  verify  stock-on-hand  before 
filling  a  request.  The  Maintain  Stockagc  Levels 


operation  is  a  concurrent  process' (in  this  instance  an 
Ada  task)  that  compares  the  present  stock  inventory 
with  minimum  sustainment  levels  and  calls 
TRANSACTION  to  reorder  if  the  minimum  is  not 
met.  The  Stock  Quantities  data  is  now  decomposed 
into  the  three  data  objects  (  Stock  On-Hand,  Stock 
Due-in,  and  Stock  Due-Out)  that  are  created  by 
instantiating  an  object  constructor  (in  this  instance  an 
Ada  type). 

Figure  6  shows  the  calling  connections  for  a  scenario 
where  a  customer  submits  a  request,  the  stock  is 
available  and  is  issued,  and  the  action  causes  a  stock 
item  to  fall  below  a  minimum  level,  prompting  a 
reorder. 


Figure  6.  Supply  Object  Decomposition 
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3.0  SYSTEM  INSTANTIATION 

In  order  to  implement  a  system  with  domain  analysis 
and  design  products  as  inputs,  the  specific 
characteristics  of  a  system  are  "overlaid"  or 
instantiated  (informally)  to  the  generic  tern  elates.  For 
generic  requirements,  system-specifics  are  gathered 
from  business  process  improvement  products  (IDEFO 
and  IX  models),  interviews  with  functional 
proponents,  and  user/site  input.  The  system 
instantiation  takes  the  form  of 
insertions/modifications  of  system-specific 
information  into  the  requirements  template.  For  the 
generic  architectures,  any  system-specific  design 
features  are  added  to  (or  updated  to)  the  generic 
design  to  satisfy  implementation  constraints  and 
system-specific  requirements.  The  domain  model  and 
generic  architecture  products  will  contain  information 
about  reuse  guidance,  rationale,  alternatives 
considered  and  discarded,  and  lessons  learned  from 
the  systems'  development  and  domain  analysis  efforts. 

4.0  CONCLUSION 

Domain  analysis  and  design  allow  identification  of 
software  components  early  in  the  development  life- 
cycle,  including  the  planning  stages.  Orientation  to  a 
design  and  to  the  common  requirements  of  a  domain 
allows  the  components  to  be  larger,  more  complex, 
and  more  highly  integrated  than  traditional  reusable 
components.  These  features  can  result  in  higher  levels 
of  software  reuse  in  the  applications  within  the 
domain  of  the  architecture.  These  same  features  may 
make  a  generic  model  and  architecture  less  usable 
outside  of  the  application  domain  for  which  th„; 
were  created. 


In  order  to  realize  the  savings  required  to  meet 
budgetary  cutbacks,  a  systematic  way  of  identifying 
large-scale  software  reuse  is  necessary.  Developing 
and  using  generic  requirements  and  des:^ns  will  make 
the  difference  in  moving  a  system  out  of  the  initial 
planning  stages  into  development  and  fielding. 
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A  PRACTICAL  GUIDE  FOR  ADA  REUSE 


Robert  Haddon  Terry 
Margaretha  W.  Price 

MountainNet,  Inc. 
Morgantown,  West  Virginia 


Although  reuse  is  accepted  as  a  means  of  improving 
software  quality  and  productivity,  only  a  limited  number  of 
organizations  are  taking  its  acceptance  seriously.  Our  paper 
discusses  the  processes  involved  in  reuse  implementation.  It 
relies  upon  the  recorded  achievements  and  lessons  learned 
from  previous  and  current  projects  as  the  basis  for  its 
recommendations.  This  practical  guide  includes  a  discus¬ 
sion  of  reuse  issues,  actions,  and  benefits.  Withourproposed 
approach,  an  organization  can  gain  confidence  through  a 
low-cost,  modest  reuse  program,  while  developing  valuable 
reuse  expertise.  Findings  are  presented  in  terms  of  products, 
which  include  information  for  initiating  and  managing  a 
reuse  effort 


Several  experts  recommend  the  implementation  of  re¬ 
use  throughout  all  phases  of  the  software  development  life 
cycle.  Dr.  Kyo  C.  Kang  of  the  Software  Engineering 
Institute  proposes  refiring  the  life  cycle  model  to  include 
reuse  activities  at  each  phase.1  Dr.  Charles  McKay,  a  NASA 
scientist,  emphasizes  the  importance  of  developing,  import¬ 
ing,  classifying  and  leveraging  reusable  components  through¬ 
out  the  Space  Station  Program  life  cycle.1 

Even  though  it  may  be  apparent  that  reuse  activities 
should  be  included  in  all  phases  of  the  development  life 
cycle,  economic  constraints  and  managerial  attitudes  have 
limited  its  implementation.  We  have,  therefore,  elected  to 
limit  our  scope  of  concentration  to  the  code  development 
phase. 

In  the  coding  phase,  visible  benefits  are  more  readily 
identified.  Reuse  at  this  phase  can  easily  be  defiled  by  the 
ratio  between  DLOC  (Developed  Lines  of  Code)  and  RLOC 
(Reused  Lines  of  Code).  The  benefits  of  reuse  are  not  so 
immediately  evident  or  measurable  during  the  other  life 


cycle  phases.  For  instance,  during  the  design  and  testing 
phases,  due  to  the  artistic  nature  of  the  activities  involved, 
it  is  difficult  to  calculate  time  spent  or  saved. 

Before  we  outline  our  recommended  approaches,  let  us 
first  report  on  our  investig?lion  of  the  current  issues,  expe¬ 
riences  encountered,  and  lessons  learned  by  other  reuse 
efforts. 


Selecting  a  practical,  achievable  reuse  approach  is 

facilitated  by  a  clear  understanding  of  the  issues  relevant  to 

adoption  and  implementation.  These  issues  and  questions 

include: 

-  Development  Methodology  -  During  which  life  cycle 
phase,  e.g.,  coding,  design,  testing,  and/or  documenta¬ 
tion,  should  reuse  approaches  be  applied  to  achieve  maxi¬ 
mum  efficiency? 

-  Analysis  Techniques  -  Which  of  the  analysis  techniques 
produce  intuitively  clear  and  achievable  paradigms  of  a 
practical  reuse  approach? 

•  Assessment  Approaches  -  Which  assessment  approaches 
best  identify  those  reusable  artifacts  most  relevant  to  a 
given  developer’s  needs? 

•  Multiple  Instances  -  How  should  multiple  instances  of 
reusable  artifacts  be  constructed? 

-  Integration  •  How  best  are  the  aforementioned  activities 
integrated  into  the  other  life  cycle  phases? 

-  Presentation  -  Which  presentation  methodologies,  e.g., 
modeling  and  diagramming  techniques,  best  suit  a  given 
developer’s  needs? 

-  Testing  -  Which  testing  methods  most  adequately  ensure 
the  integrity  and  viability  of  the  approach  selected? 

-  Management  -  How  are  policies  regarding  research,  quality 

control,  and  information  dissemination  defined  and  imple¬ 
mented? 
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Practical  Approaches 

Certain  basic  steps  and  practices  have  been  effective  in 
addressing  and  overcoming  reuse  implementation  chal¬ 
lenges.  The  following  briefly  describes  proven,  fundamen¬ 
tal  measures  which  support  sound  approaches. 

-  Investigate  the  systematic  and  limited  use  of  existing  reuse 
successes.  In  particular,  apply  theories,  which  are  just  sets 
of  axioms,  to  activities,  thereby  utilizing  the  most  current 
actual  advances. 

-  Set  a  clear  distinction  between  small-,  medium-,  and  large- 
scale  reuse  opportunities. 

-  Provide  the  reuse  effort  with  a  comprehensive  variety  of 
software  development  information. 

-  Effectively  and  definitively  rely  upon  reuse  successes  to 
maximize  the  reuse  effort. 

•  Provide  support  for  different  development  methodologies 
at  different  stages  within  each  model. 

Recommendation:  Reuse  Expert  (REl 

The  above  suggestions  are  certainly  warranted  and 
needed,  although  they  lack  a  means  for  implementation. 
One  solution  is  to  create  a  new  position  called  a  Reuse  Expert 
(RE). 

Suggested  qualifications  and  responsibilities  which  the 
RE  should  attain  over  time: 

-Bea  full-time  memberofthedevelopment  team,  whose  sole 
responsibility  is  to  the  reuse  effo:i  itself. 

-Be  a  senior  staff  member  who  is  held  in  high  regard  by  the 
development  team  and  displays  a  positive  attitude  towards 
reuse. 

•Participate  in  the  analysis,  design,  and  coding  phases  ofthe 
development  process. 

-  Attend  all  team  reviews  and  walk-through  demonstrations 
to  facilitate  constructive  communication  and  to  avoid 
duplication  of  effort. 

-  Research,  analyze,  and  report  on  reuse-related  resources. 

-  Obtain  trairing  in  areas  relevant  to  his  experiences. 

-  Maintain  the  common  and  shared  in-house  software  re¬ 
positories,  monitoring  access  and  growth. 

•Avail  himself  of  and  exploit  all  opportunities  in  training  the 
development  staff  in  relevant  reuse  materials. 

-  Communicate  reuse  development  needs  to  management 
and  gain  expertise  great  encjgh  to  warrant  shifts  in  the 
development  paradigm. 

•  Expose  his  findings  to  the  reuse  community  by  publishing 
demonstrating  or  attending  cum....  forums. 


Information  Gathering 

We  began  by  performing  a  thorough  investigation  of 
possible  candidates.  Quality  controls  included  verification 
and  validation  of  sufficient  source  documentation.  We  then 
attempted  to  identify  and  locate  supporting  material  for  the 
list  of  chosen  possibilities.  The  resulting  materials  were 
analyzed  and  initial  candidates  identified  using  the  defined 
quality  measures. 

We  then  created  and  issued  an  informal  survey.  The 
survey  included  questions  regarding  the  current  level  of 
reuse,  the  number  and  position  of  persons  involved,  and  the 
nature  and  instances  of  reliance  upon  repositories  versus  the 
availability  of  COTS  (Commercial-off-the-Shelf)  compo¬ 
nents. 

We  originally  intended  to  target  the  survey  to  six  or 
more  high-level  managers  or,  at  the  very  least,  those 
individuals  most  likely  responsible  for  a  reuse  endeavor. 
Afteraseriesoffrustratingcontacts  with  voice  mail  systems, 
answering  machines,  secretaries,  andbeleaguered  colleagues, 
we  concluded  that  access  to  this  target  audience  was  not  only 
exhausting  but  difficult  to  obtain.  However,  those  surveys 
which  were  completed  and  returned  were  scrutinized  to  be 
sure  the  answers  provided  could  be  verified.  We  then 
analyzed  the  responses  and  selected  three  Ada  software 
development  projects  which  not  only  represented  the  variet;  > 
of  available  development  approaches  but  also  displayed  1 
penchant  f~r  reuse.  Again,  quality  guidelines  were  estab¬ 
lished  and  included  such  issues  as  size,  direct  contact  with 
members  integral  to  the  effort,  and  the  receptiveness  of  these 
individuals  to  incendiar  r  ^estions  and  comments. 

Data  Presentation  and  Analysis 

In  order  to  preserve  audir  bjectivity,  we  elected  to 
present  the  information  anonyi  .tasty.  Although  we  have 
been  granted  permission  »  T  H>.e  full  disclosure  of  our 
findings,  particularly  since  most  are  currently  and  readily 
available,  we  feel  it  serves  no  purpose  to  aitach  our  sugges¬ 
tions  to  any  particular  endeavor.  'Ve  are  attempting  to  offer 
solutions  which  could  be  used  by  any  effort.  Indeed,  it  is  our 
hope  that  these  scenarios  result  in  a  better  understanding  of 
reuse,  its  properties,  and  its  acceptance. 

Project  A 

General  profile:  A  multiuser  information  system 
encompassing  an  inventoty  control  system  with  command 
decision  modules. 
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Demographic  data:  The  system  consists  of  300,000 
LOC  (Lines  of  Code)  ana  took  approximately  two  years  to 
develop.  Testing  was  slated  for  ’anuary  1992.  A  total  of  25 
assigned  software  developers  have  been  involved  on  a  full 
time  basis.  There  were  also  more  than  five  support  personnel 
and  some  outside  contracting.  The  developers  had  different 
roles  including  three  system  administrators,  four  communi¬ 
cation  specialists,  two  database  administrators,  one  configu¬ 
ration  manager,  and  more  than  five  teams  of  2  to  3  applica¬ 
tion  developers. 

Reuse  achievements: 

-  New  development  efforts  have  adopted  their  methodology, 

standards  and  software  architectures. 

-  A  scarcity  of  off-the-shelf  software  required  the  develop¬ 
ment  of  an  Ada  configuration  management  system  which 
will  also  be  exported  to  other  systems. 

-  The  methodology  has  been  documented  in  a  much  needed 

“Developer’s  Guide”.  The  guide  shows  potential  as  an 
organizational  standard. 

-  Approximately  6,000  lines  of  locally  written,  reusable  code 

(12%  of  the  total  lines)  equals  30%  of  the  system  based  on 
the  number  of  times  they  have  been  reused. 

-  A  page  formatting  component  was  reused  from  the  ASR 
(Ada  Software  Repository). 

-  GRACE  Components  were  purchased  and  used,  albeit  not 
extensively. 

-  Preliminary  discussions  have  begun  about  their  own  in- 
house  repository. 

Reuse  lessons  learned: 

•  Lack  of  tools.  Very  few  commercially  available  tools  had 
been  developed  which  appropriately  fit  their  needs. 

•Unanticipated  tasks.  Searches  for  reusable  artifacts  had  to 
be  conducted,  prices  negotiated,  and  testing  of  the  pro¬ 
cured  products  had  to  be  accomplished. 

-  Lack  of  resource  knowledge.  Greater  emphasis  should 
have  been  placed  upon  searching  Ada  repositories  for 
specific  software  requirements  and  developing  packages. 

•  Lack  of  component  support.  A  support  group  for  the 
purchased  reused  components  was  created  and  later  dis¬ 
banded.  The  product  was  never  made  fully  available. 

-  Program  reviews  were  attempted  to  increase  the  amount  of 

information  sharing,  but  they  were  discontinued  because 
of  time  and  coordination  constraints. 

-  Unanticipated  ramifications.  By  judicious  integration  of 
the  database,  control  files,  and  reusable  packages,  varying 
field  requirements  and  development  modifications  were 
affected  by  minor  system  tuning. 


Recommendations: 

-  The  project  should  have  retained  one  RE. 

-  The  RE  should  have  seen  to  the  organization  and  produc¬ 
tivity  of  the  program  reviews. 

-  The  RE  should  have  coordinated  and  managed  reuse 
component  acquisition  and  purchase. 

-  The  RE  should  have  constructed  an  in-house  repository 
beyond  the  initial  and  immediate  needs  of  the  current 
development  project. 

-  The  RJE  should  have  been  responsible  for  repository 
searches  and  retrievals  as  encountered. 

Project  B 

General  profile:  A  financial  system  which  is  an 
application  redesign  that  services  an  accounting  and  finance 
center. 

Demographic  data:  The  system  consists  of  2.75  mil¬ 
lion  LOC  with  a  total  development  time  of  4. 5  years.  Of  this 
total,  approximately  two  years  were  spent  coding.  The 
system  was  delivered  to  the  customer  after  development  and 
qualification  testing  was  completed.  A  total  of  90  people, 
including  52  coders,  were  directly  involved  at  the  peak 
period.  Responsibilities  were  divided  among  management, 
database,  senior  analyst,  system  support,  advanced  technol¬ 
ogy,  application,  design,  and  application  generatcr  teams. 

Reuse  achievements: 

-  Portions  of  the  design  were  isolated  into  packages.  This 
permitted  a  physical  decomposition  of  code  rather  than 
decomposition  along  functional  lines. 

-  Timing  issues  were  encapsulated  in  a  single  mainline 
generic  package  for  reasons  of  consistency.  Over  time, 
advantages  were  found  by  having  several  mainline  ge¬ 
neric  packages.  A  benefit  of  this  approach  was  that  every 
funct/o  -  ,'bsystem  had  the  same  “look  and  feel”. 

-  A  folk  -  v  inventory  project,  about  one-third  the  size, 
used  the  tools  created  and  reduced  its  cost  by  one-half. 

-  Each  of  the  more  than  2,500  data  items  was  defined  in  a 
database.  Centralized  management  of  data  item  typing 
enforced  an  uncommon  level  of  consistency  throughout 
the  code. 

-  All  interactive  programs  bad,  by  definition,  exactly  one 
screen.  A  screen  painting  tool  was  used  to  generate  the 
code  necessary  for  the  screen  and  its  system  mapping 
support. 

-  Specifications  were  used  as  input  into  a  generator  which 
generated  bodies.  A  full  76%  of  the  2.4  million  lines  of 
code  were  generated. 
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*  Code  sharing  wa*  supported  by  creating.  distributing,  and 

using  common  and  shared  tihrane*  Walk  through  pro¬ 
vided  opportune  ten  to  share  the  knowledge  of  libranr*' 
content* 

-  Common  code  <e  g  ,  a  men  pac  kagr)  and  shared  code 
(e  g  ,  date  operator*)  were  maintained  and  m*>k  avail¬ 
able. 

Resiar  Irsaoat  Warned 

- |j*k  of  communit  ation  Communication  between  library 
uaert  wa*  difficult  to  maintain  and  facilitate  It  was 
partially  alleviated  by  an  application  leader  w  bo  asttumed 
monitoring  rraponwhilrt*** 

*  Limited  nee  of  resource*  l  **e  of  tie  Moor  h  component*  and 

ASR  win  minimal  *itve  the  developer*  feared  their  intro¬ 
duction  would  result  in  configuration  management  protv 
km* 

-  lack  of  coordination  line  power!  rl  senior  design  team  did 

no*  cwmmiinrotfe  the  properties  of  reuse  effectively 

-  Unanticipated  ramification*  later  in  the  development, 
project  reuse  effort*  were  con«i*rently  impeded  by  data- 
base  diffuultie* 

*  Lack  of  integration  Walk  through*  became  internal  team 

meetings  while  information  sharing  wa*  limited  to  segre¬ 
gated  group*  There  wa*  very  little  reuse  between  group* 
at  the  application  level 

*  Lack  of  in-hou*e  repository  The  effort  lacked  an  in  House 

repository,  which  could  have  also  nerved  as  a  storage  unit 
few  the  *pe<  i  fi  tat  ions  used  with  the  generator 

ReCMMoeadstiocM 

*  The  project  ihould  have  retained  two  Rl  * 

*  The  Rla  ihould  have  marie  intr*  team  communication  a 
priority  and  should  have  been  present  at  «a«h  walk¬ 
through 

-  The  Rl4  ihould  have  taken  full  advantage  of  the  mne 
opportunities  provided  by  the  Hooch  component*  and  the 

AS* 

.  The  MU  ihould  have  maintained,  monitored,  and  diiaemi  • 
anted  the  common  and  shared  library  content* 

*  The  RFa  ihould  have  hern  im  luded  in  the  dec  toon  making 

session*  held  by  the  *enior  design  team 

*  The  RL*  should  have  planned  for  later  mm  effort*  by 
automating  data  change*  with  took  that  could  handle 
increased  popsdaiton* 

tatifUC 

General  profile,  ka  advanced  automated  iryitem  for 
avtatioa  The  «y*tent  »*  preaewty  broken  Into  16  logical 


groups,  whre  h  art  u  tprtyrd  of  about  4 a  large.  distirtMcd 

pcsrwt 

De  mographU  data  The  find  prmhwl  will  require  an 
estimated  ?  1  nullum  Ad*  I  IK',  phretoow  K>\1A!  (  and 
Acer richie r  software  mived  with  (  tflS  IV  «v tr-m  is 
currently  under  development  and  la*  a  dmel-ymt-rst  ftf** 
cycle estimated  to  last  I 2  rears  wish  a  n«>n*r«vatfc  t  please 
greater  than  to  year*  TV  re  are  ovt>  I  r  opt  vo  from 

multipk  compame*  working  on  tV  project  T  T*e  survey  eu 
company1*  involvement  intitule*  ' propk  who  work  in 
approsimatfdy  4 '  groups  otw-  of  who  h  **  »  reuse  working 
group  ( RWG)  that  has  1 1  fed  t  time  amt  I1’  p>v  time  pad  hi 
pant* 

Reuse  arhkvementr 

•  An  ad  tvs  working  group  was  set  up  as  a  tack  Piece  of 
interested  volunteer*,  to  determine  hrov  tV  project  could 
take  adv  antage  of  tense  tec  hiwdogv 

-  The  wotiing  group  evolved  into  an  offu  »*J  organiratem 
which  provide*  •  project  wrdr  cnofdroaUtm  of  the  reuse 
effort 

-  The  RWG  defined  a  reuse  pro*  ess  and  established  re  spun 

lihtline*  for  ear  h  of  it*  nvrmVt*.  who  h  are  d<*  umc.md 
in  the  project  *  development  wandattH 
.  The  RWG  defined  role*  ami  rrsjvw.uhilttie*  fro  softer** * 
author*,  reuser*.  andreuae  artvivate*  IV#e  ttvhatf  tiem* 
which  assure  the  quality  of  IV  reuse  product*,  protease* 
compwni*.  ami  people 

-  U*ing  a  literary  w  an  ant  lec  h.mpie  on  t he  in  house  compo 

lirnt*.  the  RWG  performed  *n  aMirrviared  domain  analy 
lit  Initially,  lot  different  classes  were  rdrntified  that 
could  he  potentially  ( re  breed  I  v  two  or  more  deyehquiwnl 
group*  within  the  project 

-TheRWGltarkediHc  development  «ae  and  change*  of  the 
reusable  component*  They  acbertised  the  components 
and  their  "re crew”  s.  htdulf* 

-  Ikh  development  group  t*  “*nr<  Haigd"  for  retisr  by 
taking  out  the  cost  of  the  Reuse  Group  fiom  *a»  h  of  the 
development  groups  budget*  ll  I*  hoped  ihrv  wostld  take 
advantage  of  what  they  are  paving  for 

•  The  *hanng  of  software  (up  to  t  time*  in  cure  caaei  hared 

the  ihartng  of  inhumation  between  diftrfeni  development 
groups,  whic  h  Inc  teased  the  umVitUnchng  of  the  problem 
domain  and  raised  each  p*rti<  ipant*'  level*  of  rsprrtue 

•  The  R  WO  searched  various  forum*  and  rejxvsitorv*  (e  g  . 

in  house  reprmtoree*.  AdaNI'T,  CT)SMIt\  GRAtT,  and 
STARS) 

•  The  RWG  recommended  "rewind**  and  other  incentive* 

for  participation  in  component  reuse 


~A|*rfr  aH»Mg»fttM<r.*-v*.  .ijwWni»aiJ^iyr>Hfc»  wfr*  *»-  (U-^  V.  uvr«£j*  ’  «**».iAuC5'4M»6-~^ *. .  ■*>,-  ■  .' 


fr&Vjfc)*  'fiw'dlfc~*U, 


"Hx.  H  W< !  member*  *tt'n.t«*d  a!1  ptnjal  review*  and  «ooght 
o»M  npjvxlnnoir*  for  rr>»«* 

■  J  Iwf  K  W  l !  niyiiwd  pr*vie  *U>iit  the  re  use  p»  tivitu**  »t  thru 
reuse  center,  they  also  prrpsrfd  anil  amipdid  mrvm 
from  user* 

Rmw  Irusm*  learned: 

•  IV-  "tradit tonal"  software  development  process  must  he 
modified  to  incorporate  the  mice  effort 

■  It  ws*  discovered  ihat  mote  granularity  inti*  king  data  was 

needed  Originally.  tiny  only ’t*  ked  reuse  at  the  'irun- 
poirrnl"  level 

.  I  to.  nment  ««,yo.|artt<  have  to  hr  tailored  fin  reuse  since  they 
t‘i  pt  »l!>  require  inappropriate  inhumation  and  formats 

-  I  here  nerd*  to  la-  more  automation  of  (In'  pi  ore** 

-  Raise  must  he  constd*  ini  early  in  the  life  in  If,  at  the 
«p»v  ifn  atom,  nr  even  the  proposal  (tape 

•  Area*  when  potential  rr usaUr  components  air  identified 
would  need  esim  funthn«  to  develop  (hr  itimporwnts 

Her  ommrndatlnns: 

•  The  R  W< ;  shimld  lontimie  mutiny;  progressive  steps  in  the 

rilin'  effort* 

•  1  hr  R  WU  should  *nh  divide  *hrit  effort*  in  order  loreflect 

their  mm  run  with  the  proposal,  design,  deve lopntent, 
•ml  mmntdvrn.  e  of  the  product 
- 1  he  mission  of  (tie  R  WO  should  blither  be  a  comprehensive 
reuse  fffort.  and  not  fa'  assoi  rated  with  any  particular 
attempt 

f'rtiit  nlar  roles  within  eat  h  sub  group  need  to  hr  identified 
and  rmph isi/od  (eg,  HP.,  liomatn  Analyst*,  Domain 
I  s|a  rt  i  tv  ) 

1  heit  effort  irniM  iru  hide  (may Ik  should)  al  least  font  RF* 

1 1 8sJ#  $i*d  jV J<  t « it  JFmr«oi 

M  i«  oweption*  regarding  reuse  have  hampered  aeoqy- 
tam  r  I  ai  liar  many  deve  topers  adhere  to  the  myth  that  Wise 
it  a  costly  and  generally  risky  business  Prop'll*  ate  quite 
often  overly  ambition*  with  til  defined  goal*  and  inflated 
tspes  tations  llowrvrr,  if  the  effort  i*  modestly  undertatirn 
and  ha«‘d  upon  a  foe  used,  concentrated.  and  ilcarty  stated 
mission,  the  overall  costs  will  he  negligible  llahvnce  those 
io»t*  against  the  practical  fspertemea  learned,  and  (lie 
argument*  against  reuse  effort*  are  Its*  compelling 

helming  and  supporting  a  qualified,  enthusiastic,  and 
responsible  team  leader  are  essential  to  any  effort  For  our 
purposes,  this  person  it  designated  the  RF  Returning  Ihc 
« *;*  n  ftom  an  r  siding  team  and  positioning  him  in  this  new 


least  role  tan  he  viewed  as  an  initial  investment  IV  number 
of  reuse  enjrcrts  non  wiry  mud  be  measured  again**  itie  staff 
and  profit  size  The  'tumher  of  Rls  mat  *,'«<  grow  in 
response  to  project  growth  and  maturity  f  or  nvwl  n**b*i 
ptojci  ts,  (me  full  tone,  committed  expert  i*  tuffi-.  »ent  This 
commitment  must  be  total  time  the  rcsponsihduu-*  m 
volved  in  reuse  demand  constant  evatuafion,  intervention, 
ami  control  Purther  qiiahfli  at  ions  are  detailed  in  following 
Motions 

(hue  nppoinicd,  the  reuse  espert  will  liven  be  required 
to  esaluate  in  house  packages  and  ixmqyinents  We  hoe 
adopted  the  term  ’obiecU*  to  rrpresenf  paikages  amt  or 
components  ('ompame*  with  estensivt  i#>fe<t  toihxiions 
should  make  judn  ion*  selection*  folding  ot'jm  li  di.n  mat,  h 
the  efforT*  gimt  and  mission  Smaller  firm*  wlm  hast  m 
pr  wlmed  last  armnint*  of  aide  tan  choose  to  rc jxivment 
with  all  the  objects  collected 

Ideally,  a  amiprehensive  doniam  analysis  would  be 
perforr.ied  at  this  (mint  Our  espericme  inde. ales  that  an 
"abhrevtaird  do*  *ain  analysis",  performed  hy  tl>e  HP,  is 
more  practical  and  useflil 

This  entail*  using  a  form  of  the  literary  warrant  lah 
nii|iie  employed  by  library  tcientisls  In  this  tnhmquc, 
rsisting  ofi|«  ts  are  grouped  aawding  to  their  tommonah- 


A  brief  r sample 

I  irnt  XV/  has  tlu*  following  seven  objects 

*  simple  edime 

*  lest  formatter  p«  kage 

-  random  number  generator 

-  array  manipulation 

*  s|s,'ll  thei  ker 

*  binary  tree  functions 

-  matrix  function* 

FVrformmg  an  abbreviated  analysis  could  result  in.  hut 
Is  certainly  mil  limited  to,  the  following  grouping 

Gump.  Tcvi  Manipulation 
Simple  editor 
Test  formatter  package 
Spell  checker 

OrwD,  Maikmaiical  Roulinci 
Rancfom  rumher  generator 
M.itrts  fiiiHtlons 


Grow  Abstract  Data  Tyuci 

Arm  manipulation 
Binary  trw  functions 

Obviously,  there  sre  many  method*  of  analysing  and 
ciaMifvtng  ohyrt.ii  uamg  *  variety  of  nomenclature* 

Computer  Scknor  Corporation's  Reuse  Working 
Grtaip  for  example,  did  something  they  called  a  “mini 
domain  analyst*"  which  wan  in  identifying 

common  classes  and  fin  (liUting  communication.' 

With  the  existing  object*  grouped,  the  reuse  expert  can 
thro  diw-itts  their  relevance  with  developer*  who  will  be 
encouraged  to  rate  the  necessity  of  each  object  to  their 
current  project  Developer*  will  also  be  ashed  to  produce 
a  lit*  of  object*  for  pmcihle  acquisition  or  development 
This  proofs*  i*  vital  for  building  confidence  in  the  overall 
mt*  effort 

Developer*'  feedback  will  provide  the  reuse  expert 
with  two  li(U  of  object* 

1  in  house  objwt*  deemed  necessary  to  the  project  at  hand 

2  "la  demand"  object*  which  must  he  located,  and  re¬ 

trieved,  part  haded  or  developed 

If  there  «xi*l  in-house  object*  which  developer*  thin* 
they  need,  they  can  Ju«t  make  a  copy  and  rru*e  it.  Other* 
wiae,  the  developer  meet*  with  the  RF.  to  decide  whether  • 
term  of  the  object  I*  on  the  "in  demand"  lint  and  whether 
the  demand  i*  great  enough  to  warrant  developing  It  a*  a 
reusable  object  at  thi*  lime  If  it  U  appropriate  to  develop 
Mata  reusable  object,  the  RF.  will  organize  and  coordinate 
the  affbrt  with  the  other  potential  user*  of  the  object.  The 
coordination  would  Include  identifying  the  common  re¬ 
quirement  t  and  der  iding  on  which  developer  could  handle 
the  extra  work  load 

Management  need*  to  encourage  the  development  of 
rateable  object*  by  allotting  more  lime  for  the  effort 
Developer*  need  to  share  the  responsibility  of  creating 
twuaable  object* 

frsductl: 

RE  Rttpomlbilitieg  gudActivitifi 
QattflUltoil  «f  the  ttadldatti 

Candidate*  need  to  be  experienced  la  the  development 
pence**  Ideally,  they  should  also  be  students  of  the  reu*a 
effort  They  must  posse**  the  abilities  to  offer  and  promote 


procedural  shifts  in  the  organization's  developmental  para¬ 
digm  Fina'fy.  they  mutt  be  prepared  to  manage  and  enlarge 
upon  the  reuse  effort 

llfKJBISSUKl&i^^ 

Beginner 

font*  Research  and  analyze  what  ha*  been  done,  focus 
attention  toward*  what  it  needed  Complete  the  follow¬ 
ing  recommended  activities  until  satisfied  of  suoceat 

Activities: 

•  Gather  and  maintain  information  about  the  in  house 
software  domain 

•  Gather  and  analyze  information  concerning  the  reuse 
paradigm  shifts 

•  Contact  and  interact  with  any/all  potential  oomjx*nent 
source*  for  your  domain  of  interest  (e  g ,  rtpoaiioriet  or 
commercial  components) 

-  Perform  an  abbreviated  domain  analysis  of  in  house  srti- 
fncts 

-  Locate  and  enroll  in  one  or  more  reuse  work*hopt/tutori*l« 

-  Gather  and  analyze  information  about  related  subject  area* 

(e  g ,  Domain  Analysis.  Designing  for  Reuse,  Library 
Science*,  etc  )  a*  they  are  encountered  and  become  rel¬ 
evant  to  your  effort 

•  Attend  and  participate  in  any/all  program  reviews,  design 
reviews,  etc 

-  Reproduce  snd  distribute  all  relevant  products  (e  §.,  cata¬ 
log  of  In-house  component*,  report  of  external  compo¬ 
nents,  etc  ). 


Intermediate  . . _ 

Pens  Continue  effort*  In  researching,  analyzing 
docs  anting  and  reporting  Begin  introducing  reuse  a* 
an  alternative  to  development,  focus  on  easily  understood 
and  worthwhile  attempts 

Aethitl  s 

•Prepare  for  work»hop*/tuu*ri»li,  read  relevant  publication* 
of  the  speakers  or  the  subject  Communicate  *ny  question* 
and  special  Interests  with  the  speakers  (allowing  them 
time  to  address  the  questions  in  the  session) 

*  Attend  wortihopsAutortaJs,  obtain  and  briefly  review  all 
the  provided  material  Ask  questions  as  they  arise,  offer 
suggedion*  when  solicited  Review  and  prepare  for  each 
seasiofl  (e  g  ,  during  breaks  or  overnight  stays) 


-  Create  a  summary  report  of  lessons  learned  from  the 
workxhops/tutorials  Include  ideas  which  might  he  imple¬ 
mented  in  your  company 

•  Continue  attending  and  participating  (more  actively)  tn  in- 

house  program  review*  Seek  out  and  select  one  or  more 
opportunities  for  reuse 

•  Keep  accurate  records  on  the  selected  reuse  opportunities 

1  rack  hour*,  LOC.  and  other  data  which  can  be  used  to 
evaluate  the  reuse  effort  Record  all  data  in  •  spreadsheet 
package 

•  Propose  the  purchases  of  commercial  components.  if  their 

contents  fulfill  your  domain  needs  Include  the  compo¬ 
nents  in  the  in-hoose  library  and  distribute  information 
about  them  to  potential  users 

-  Reiterate  the  abbreviated  domain  analysis,  to  provide  finer 

granularity  ami  to  identify  obvious  omissions 

•  Create  a  taxonomy  (listing)  and  an  architecture  (model)  of 

the  in  house  library 


Ei  pert 

Focus  Continue  with  the  carry  over  activities  of  the 
prior  levels  Propose  instances  where  reuse  should  occur 
lisc  obtained  data  to  statistically  demonstrate  the  value  of 


Activities: 

Conduct  reuse  training  when  appropriate  and  needed  The 
training  should  be  short  and  directed  towards  the  audience's 
abilities 

*  Provide  management  with  a  reuse  activity  report  Include 
statistics  that  demonstrate  (tie  value  of  the  cfTort  Include 
paradigm  shifts  which  wvtuld  improve  the  process 


Create  a  reuse  working  group  (possibly  from  volunteers) 
who  have  the  qualifications  needed  to  improve  upon  the 
reuse  effort 

Pcrfcm  an  abbreviated  domain  analysis  of  the  external 
resources  previously  identified  Prepare  a  taxonomy  (in¬ 
clude  price  information)  and  an  architecture  of  the  ones 
which  arc  part  of  your  in-house  domain 
Psopose  and  solicit  places  where  reuse  is  needed  from  the 
working  group  members  Prepare  a  report  which  demon¬ 
strates  the  potential  value  of  your  suggestions  Deliver  the 
report  to  those  in  charge  of  making  such  decisions 
•  Attempt  to  publish  your  experiences  and  findings 

Product  3: 


Our  paper  thus  far  has  introduced  a  basic  reuse  program 
involving  minimal  start-tip  costs  Tins  basic  introduction 
can  and  should  be  expanded  upon  to  achieve  maximum 
benefits  This  expansion  will  be  made  possible  by  an 
increased  level  of  expertise  and  cfTort  maturity  Moving  the 
effort  forward  is  a  natural  progression  for  both  the  RF:  an  1  the 
project  itself  Figure  I  illustrates  this  point  by  combining  the 
steps  outlined  in  the  Section  .  "How  to  Start  A  Reuse 
Program",  and  the  following  Section  which  tracks  the  RFs 
expanding  level  of  expertise  The  figure  also  provides  cost 
and  time  estimates  for  each  iteration  necessary  to  ac  hieving 
the  ultimate  goal 

The  time  consumed  by  increased  reuse  activities  de¬ 
pends  upon  a  variety  of  factors  which  impact  project  deci¬ 
sions  Renown  reuse  and  domain  experts  such  as  Ruben 
Prtcto-Dia/  support  the  idea  of  progressive  reuse,  e  g ,  reuse 
achieved  through  a  series  of  stages  based  upon  underlying 
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FIGURE  1  REUSE  PKOCRAM  STAGES 
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success  >1  each  level 4  We  concur  and  support  this  conten¬ 
tion  graphically  in  Figure  I .  Note  that  allowances  are  made 
for  both  progressive  and  horizontal  iterations.  Horizontal 
iterations  are  performed  when  unsatisfactory  results  occur  at 
any  given  level. 

Figure  I  also  shows  that  cost  allowances  increase  as  the 
project  matures.  This  is  typical  of  reuse  efforts  and,  as  noted 
by  Prieto-Diaz,  most  projects  will  experience  fluctuating 
costs  before  stabilizing  Figure  2  represents  typical  cost 
behavior.4 


tmplrmvntvtioa  Inryein 
nOOnt  2  ■  Rqp*rU4Co«t  Brfumor  •  Typual  Rnui  Fto| 


The  most  important  factor  influencing  the  success  or 
failure  of  a  reuse  effort  is  undoubtedly  the  RE,  his  commit¬ 
ment  and  expertise  Management  must  enforce,  if  neces¬ 
sary,  the  total  imolvcment  of  the  RE  in  all  aspects  of  the 
software  development  life  cycle.  The  number  of  REs  in¬ 
volved  in  the  project  depends  upon  the  nature  and  level  of  the 
project  itself.  Any  reuse  effort  will  be  shortchanged  if 
management  underplays  the  importance  of  this  role. 

As  reuse  is  integrated  further  into  the  development 
process,  the  number  and  involvement  of  REs  increase  ac¬ 
cordingly.  The  RE's  role  should  expand  in  all  other  phases 
of  the  software  development  life  cycle. 

Management  should  support  the  reuse  efTort  by  reward¬ 
ing  the  development  team  with  creative  incentives.  Devel¬ 
opers  who  successfully  reuse  code  or  create  reusable  code 
should  receive  management  recognition  or  tangible  re¬ 
wards  Management  should  make  available  articles,  papers, 
and  any  current  information  on  the  subjects  of  reuse,  and 
should  encourage  their  utilization.  One-hour,  weekly  status 
inertings  should  be  scheduled  to  facilitate  the  lnformation 
sharing  on  the  reuse  effort  and  its  impacts  on  current 
projects. 
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The  following  is  a  representative  sampling  of  available 
resources.  It  is  meint  to  serve  as  a  good  starting  point  for 
beginners  and  as  template  for  the  data  structure. 

File:  Commercial  Components 

Record  Name:  Booch  Components 
Vendor:  Rational 
2171  South  Parfet  Court 
Lakewood,  CO 
Phone:  (303)986-2405 
Contact:  Grady  Booch 

Abstract:  Consists  of  several  dozen  domain  independent 
data  structures  and  tools,  each  with  multiple  implementa¬ 
tions  so  that  a  client  can  select  the  represcntaJon  that 
provides  the  most  suitab!;  time  and  space  characteristics. 
Although  written  in  Ada,  Versions  are  planned  for  C# 
and  SmallTalk.  Over  300  sites  in  the  US,  Europe,  and 
Pacific  Rim. 

Vendor  Profile:  Rational  is  recognized  as  the  world's 
leading  supplier  of  Ada  products  and  services.  Grady 
Booch  is  Rational's  director  of  object-oriented  product 
development  as  well  as  the  developer  of  the  Booch 
Methodology  and  Booch  Components. 

Record  Name:  The  GRACE  (Generic  Reusable  Ada 
Components  for  Engineering) 

Vendor:  EVB  Software  Engineering,  Inc. 

3303  Spectrum  Drive 

Frederick,  MD  21701 

Phone:  (*00)693-1815 

Fax:  (301)695-7734 

Contact:  Jennifer  Jaynes  Lott 

Abstract:  Consists  of  273  distinct  components  organized 

into  23  families  of  abstractions  which  total  more  than 

320,000  lines  of  Ada  Code.  GRACE  components  and  the 

18,000  pages  of  documentation  are  provided  on  magnetic 

media. 

Vendor  Profile:  EVB  provides  consulting  services  to 
assist  management  and  technical  teams  in  the  absorption 
and  utilization  of  software  engineering  technology.  Also 
provides  an  extensive  Ada  Software  engineering  training 
curriculum,  products  that  enable  and  enhance  Ada 
Software  development. 


File:  Information  Service* 

Record  Name:  Ada  IC  (Ada  Information  Clearinghouse) 

Address:  4600  Forbes  Boulevard 

Lanharn,  MD  20706-4320 

Phone:  (800)AdaIC-ll 

Fax:  (703)685-7019 

Contact:  Susan  Carlson 

Internet:  qpo.sci.cmu.edu 

Abstract:  Sponsored  by  the  Ada  Joint  Progiam  Office 
(AJPO),  the  AdalC  Bulletin  Board  makes  information  on 
the  Ada  language  available  to  the  public.  Sample  flyer 
topics  include:  "Ada  Source  Code,  Reusable  Components 
and  Software  Repositories",  "Costing,  Sizing  and  Produc¬ 
tivity  Tools",  and  "Ada  Training  Videotapes  Available 
through  National  Audiovisual  Center."  The  read, me  file 
provides  a  complete  listing  of  files  available  for  down¬ 
loading  or  transferring. 

Record  Name:  archie 
Internet:  quiche.cs.mcgilt.ca 
Login:  archie 
Password:  (name  needed) 

Contact:  The  "Archie  Group"  of  McGill  University 
Bill  Heclan  (wheelan^cs.mcgill  ca) 

Peter  Deutsch  (petcr@cc.incgill.ca) 

Alan  Emtage  (bqan@cs.mcgill.ca) 

Abstract:  archie  is  an  interface  for  use  with  anonymous 
FTP  resources.  It  is  a  system  which  allows  you  to  rapidly 
locate  the  various  public  domain  programs  stored  on  the 
hundreds  of  sites  across  the  internet. 


Telephone:  Help  Desk  (800)  A  >  'J8 
Internet:  adanet.wvnet.edu. 

SprinNet:  304130 

Abstract:  AdaNet  repository  is  a  a  onentofthe 
Repository  Board  Software  Engine*.  IBSE)  program. 
The  program  provides  a  possible  donu  .eusc  library 
with  software  from  the  ASR,  Jet  Propuls,  in  Lab  (NASA/ 
JPL),  DOD/STARS,  and  Education  Institutions. 

Conclusions 

Our  study  has  communicated,  managed  and  qualified 
the  reuse  effort.  In  near  retrospect,  it  has  succeeded  as  an 
initial  analysis  of  the  reuse  domain.  We  contend  that  it  is 
worthwhile  reading  for  individuals,  groups,  and  organiza¬ 
tions  involved  in  the  rouse  effort.  We  arc  comfortable  in  the 
thought,  that  our  products  might  provide  usable  information 
in  future  attempts.  . 
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File:  Repositories 

Record  Name:  Army  Reuse  Center 
Address:  Army  Reuse  Center 
USAISSDCW,  Attention.  ASQB-IWS-R,  STOP  H-4 
Fort  Belvoir,  VA  22060-5456 
Telephone:  Client  Services  (703)  285-6272  or  DSN  356- 
6272 

Roy  Lloyd  (Newsletter  Editor)  (703)  285-907 1  or  DSN  3  56- 
9071 

Abstract:  formerly  known  as  RAPID.  Contains  1,401 
Reusable  Software  Components  ^R  5Cs)  totaling  over 
955,000  LOC.  Current  populntior  strategy  for  FY93- 
FY95  will  focus  on  identiftuJon,  valuation  and  certifi¬ 
cation  of  reusable  components. 
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USING  Ada  FOR  A  TEAM  BASED  SOFTWARE  ENGINEERING  APPROACH  TO  CS1 


AKHTAR  LODGHER  &  JAMES  HOOPER 


Department  of  Computer  Science  and  Software  Development 
Marshall  University 
Huntington,  WV  -  25755 
Phone:  (304)-696-2695  Fax:  (304)-696-4646 
Internet:  CIS005@rr.arshall.wvnet.edu 


In  the  past  year,  the  Computer  Science  department 
at  Marshall  University  has  revised  the  Bachelor’s 
degree  program,  and  given  a  very  strong  emphasis 
to  software  engineering  throughout  the  entire 
curriculum.1  The  department  decided  to  use  Ada  as 
the  standard  programming  language  for  the  first  few 
courses.  In  later  courses,  exposure  to  other 
languages  such  as  C  and  C  +  +  is  also  given.  The 
program  has  two  capstone  courses,  taken  in  the  last 
two  semesu. ;,  where  a  major  team  project  is 
designed  and  implemented.  Htnce  the  need  for 
emphasizing  software  engineering  principles,  as  well 
as  getting  students  used  to  programming  in  teams 
from  the  very  first  computer  science  course  was 
strongly  felt.  In  this  paper,  the  author  presents  the 
syllabus  and  a  method  of  executing  the  syllabus  of 
the  CS1  course  satisfying  the  above  needs.  Software 
engineering  principles  are  introduced  early  on,  and 
after  an  initial  boot-strapping  period,  tht 
programming  projects  are  done  in  teams,  fhe  Ada 
programming  language  is  used. 

InttodygtiQB 

CS1  is  taught  as  a  4  semester-hour  course  in  a  16 
week  semester.  The  students  attend  three  hours  of 
lecture  a  week  and  two  hours  of  closed  lab. 
Concepts  introduced  in  the  class  are  reinforced  in  a 
closed  lab  setting.  An  open  lab  is  also  available  for 
students  to  complete  their  lab  exercises  and 
programming  projects.  The  Ada  compiler  on  a 
VAX/VMS  system  is  used.  Students  are  allowed  to 


use  PC  based  compiler  environments  for  program 
development.  However  all  work  is  graded  only  on 
the  VAX. 

Syllabus 

The  objective  of  this  course  is  to  develop  problem 
analysis  and  algorithm  development  skills.  Topics 
covered  in  this  course  include  introduction  to  the 
entire  life  cycle  of  software  development,  intro¬ 
duction  to  the  use  of  modular  design  in  the  problem 
solving  process,  procedural  abstraction,  decision 
structures,  iteration  structures,  basic  data  types, 
array  and  record  structures,  abstract  data  types,  use 
of  generic  code,  and  introduction  to  dynamic 
structures.  Problems  that  enhance  the  characteristics 
of  each  concept/structure  are  used.  The  problem 
solving  process  is  emphasized  over  language 
implementation.  An  example  of  this  principle  for 
illustrating  the  looping  process  is:  "Let  us  study  this 
problem  (which  requires  a  loop  construct)  and 
develop  an  algorithm  for  its  solution"  rather  than 
"These  are  the  looping  constructs  available  in  this 
language.  Let  us  see  the  kinds  of  problems  tha'  can 
be  solved  using  these  constructs". 

The  solution  process  of  these  problems  is  studied 
strictly  from  a  software  engineering  perspective  - 
conducting  a  requirements  specification  and  analysis, 
performing  a  modular  top-down  design,  development 
of  module  specifications,  adherence  of  code  to 
design.  From  the  very  first  class,  the  students  are 
told  to  perceive  themselves  as  software  engineers 
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and  designers,  not  programmers. 

A  team  approach  is  used  for  programming 
assignments  -  two  students  per  team.  One  person  of 
the  team  does  the  design  and  the  other  person 
develops  the  code  based  on  the  design.  For  the  next 
assignment,  the  roles  are  switched.  This  approach 
forces  the  designer  to  conduct  a  proper  analysis  and 
design.  The  "coder"  has  to  follow  the  design, 
making  only  necessary  changes,  if  required. 

Approach 

The  "hands  on"  approach 

The  amount  of  material  covered  in  the  class  is  qvite 
large.  To  ensure  that  enough  exposure  is  given  to 
each  topic,  a  "hands  on"  approach  to  instruction  is 
used.  Programs  which  exhibit  the  characteristics  of 
a  particular  concept  or  structure  are  made  available 
to  the  students.  These  programs  are  displayed, 
explained,  and  executed  in  the  classroom,  on  a 
computer  using  the  overhead  video  projector.  Unlike 
the  traditional  "chalk-and-talk"  approach,  this 
approach  not  only  shows  the  syntax  of  the  structure, 
but  also  shows  how  the  structure  is  used  in  the 
context  of  a  larger  solution  process.  Minor 
variations  and  nuances  of  the  structure  are  also 
explained. 

Another  important  advantage  of  this  approach  is  to 
show  the  possible  incorrect  ways  of  using  the 
structure.  When  a  student  starts  using  a  new 
structure,  the  chances  of  him  or  her  using  it 
incorrectly  are  high.  By  using  incorrectly  formed 
structures  (both  syntactical  and  semantically 
incorrect),  the  error  messages  generated  are  shown. 
The  mechanism  of  using  the  error  messages  to  trace 
the  error  in  the  structure  can  be  demonstrated. 

Class  notes  in  electronic  form,  as  well  as  all 
classroom  demonstration  programs  are  made 
available  to  the  students  (on  a  mainframe)  before  the 
class.  The  students  are  encouraged  to  bring  a 
printout  of  the  notes  and  the  programs  to  the 
classroom.  This  allows  them  to  spend  time  listening 
and  participating  in  the  classroom  discussion  and  not 
be  bogged  down  by  the  task  of  taking  notes. 


Other  advantages  of  the  hands  on  approach  inci 
increase  in  student  participation  (answering  "wha> 
questions),  increase  in  understandability  a  id  incr 
in  programming  confidence.  However,  this  apprc 
places  a  tremendous  burden  on  the  instructor, 
development  and  preparation  of  pedagoj 
examples  takes  a  lot  of  time.  Instruction  mates 
associated  with  text  books  are  not  available 
electronic  form.  Such  material  must  either 
scanned  or  typed  in  and  fine-tuned  depending  u 
the  audience. 

Course  contents  and  weekly  topics 

Table  1  shows  the  classroom  topics,  the  assignr 
anc  lab  topics  on  a  weekly  basis.  It  is  assumed 
the  student  has  little  or  no  knowledge  of 
operating  system.  However,  it  has  been  found  f 
past  experience  that  students  who  have  had 
introductory  course  on  computers  in  high  school 
more  patient  and  quicker  in  learning  the 
operating  system. 

The  first  two  weeks  introduce  the  entire  system 
cycle  of  software  development.  A  top-down  anal 
and  design  methodology  is  discussed  next, 
process  of  converting  a  problem  statement 
requirements  specifications,  analysis  and  design 
simple  problems  is  explained.  Currently  the  anal 
is  done  using  data  flow  diagrams  (DFD’s)  an^ 
design  using  structure  charts.  A  design  man 
which  explains  this  process  in  a  step  by  step  fast 
is  made  available.  The  issue  of  using  object-oriei 
design  is  under  consideration. 

The  use  of  functions,  procedures  and  package 
introduced  early  on,  in  the  context  of  mod' 
design.  AU  the  intricacies  of  procedures 
packages  are  not  covered  at  this  point.  Only 
concept  and  their  usage  in  simple  contexts 
covered.  The  branching  and  looping  constructs 
covered  next. 

Exception  handling  and  the  more  detailed  use 
functions  and  procedures  are  then  explained, 
concept  of  abstract  data  types  is  introduced.  ’ 
array  and  record  structures  are  covered  n 
Examples  of  the  use  of  array  and  records 
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Table  1:  Weekly  schedule  of  classroom  topics,  assignments  and  laboratory  exi 


Table  1: 


implement  abstract  data  types  are  explained.  It  is  at 
this  point  that  a  more  detailed  explanation  of 
packages,  passing  exceptions,  etc.,  are  discussed. 

The  concept  of  code  abstraction  is  explained  using 
the  generic  structure  on  a  sorting  example.  Finally, 
an  introduction  to  dynamic  data  structures  is  given. 
The  creation  of  dynamic  variables  and  their  use  in 
creating  linked  lists  and  traversing  linked  lists  is 
covered.  It  should  be  noted  that  the  concept  of 
recursion  is  not  introduced  in  this  course. 

Assignments  and  laboratory  exercises 

A  total  of  eight  programming  assignments  are  given. 
Of  these,  the  first  three  are  of  an  introductory  nature 
and  are  done  on  an  individual  basis.  The  latter  five 
assignments  are  done  in  teams.  The  first  assignment, 
which  is  not  given  until  the  fourth  week  of  classes, 
is  of  the  nature  of  a  "hello  world"  program.  The 
second  assignment  involves  some  output  formatting 
and  the  third  assignment  is  based  on  the  use  of 
selection  statements. 

Each  assignment  requires  the  preparation  of  a  design 
document.  This  document  consists  of:  (a)  the 
problem  statement  (b)  requirements  specifications  (c) 
analysis  -  the  data  flow  diagrams  (d)  design  - 
structure  chart  showing  the  modules  (e)  module 
design  specifications  indicating  the  input,  output  and 
processing  of  each  module.  The  design  document  is 
mandatory  and  must  be  submitted  before  starting  the 
code.  The  code  is  based  on  the  design,  and  the  close 
relationship  between  the  structure  chart  and  the 
actual  code  is  emphasized.  The  simple  nature  of  the 
first  three  assignments  helps  in  ironing  out  the 
details  and  links  between  design  and  code. 

Beginning  with  the  fourth  assignment,  the  size  and 
the  complexity  increases.  At  this  point  the  class  is 
divided  in  teams  of  size  two.  The  members  are 
chosen  using  a  draw.  One  person  is  responsible  for 
the  design  document  and  the  other  is  responsible  for 
the  code.  The  roles  for  the  next  assignment  are  then 
switched.  The  following  policy  for  grading  team 
based  assignments  is  set: 

1.  Essentially,  each  person  gets  the  grade  for 


the  work  done  by  him/her.  Each  assignment 
is  worth  100  points. 

2.  If  the  design  document  is  perfect,  then  the 
designer  gets  100  points. 

3.  If  the  code  follows  the  design  and  is  perfect, 
the  person  in  charge  of  code  gets  100  points. 

4.  If  the  design  is  correct,  and  the  code  is 
incorrect,  points  are  taken  off  from  the 
coder. 

5.  If  there  are  flaws  in  the  design  document, 
the  designer  loses  points. 

6.  If  there  are  flaws  in  the  design,  and  the 
coder  codes  it  following  the  design  (resulting 
in  badly  designed  code,  though  correct)  the 
coder  is  penalized  a  little  for  not  attempting 
to  fix  the  design 

7.  If  there  are  flaws  in  the  design,  and  the 
coder  fixes  the  design  the  coder  gets 
additional  bonus  points  for  the  extra  effort. 

8.  The  coder  shall  EXPLICITLY  point  cut  the 
changes  in  design. 

9.  The  coder  shall  not  unnecessarily  change  the 
design.  If  this  is  done,  points  are  taken  off 
firom  the  coder. 

10.  If  design  is  submitted  but  code  is  not 
submitted  or  does  not  work  then  the 
designer  gets  the  points  for  his/her  design, 
the  coder  does  not  get  any  points  for  his/her 
code.  The  coder  is  classified  as  a  "BAD 
PERSON". 

11.  If  design  is  not  submitted,  or  is  so  bad  that 
it  is  not  worth  following  then  the  designer 
does  not  get  any  points  for  the  design.  The 
designer  is  classified  as  a  "BAD  PERSON". 
The  coder  then  has  to  do  both  the  design 
and  the  code.  If  the  coder  does  just  the 
code,  he/she  gets  100  points  for  the  code.  If 
the  coder  also  does  a  good  job  on  design, 
then  bonus  points  are  given  to  the  coder  for 
the  design. 

12.  If  a  member  is  classified  as  a  bad  person 
twice,  then  on  the  first  chance  available,  that 
member  is  dropped  from  the  team  and  the 
good  person  combined  with  another  good 
person. 

13.  If  a  team  member  drops  the  course  then  the 
left  over  member  will  be  combined  with  an 
available  member.  If  such  a  member  is  not 
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available,  then  the  remaining  member  must 
do  both  the  design  and  the  code. 

The  team  policy  ensures  that  the  designer  conducts 
a  proper  analysis  and  design  and  the  coder 
understands  and  follows  the  design.  Initially,  some 
friction  between  the  team  members  was  observed, 
but  after  a  while,  the  members  were  able  to  work 
around  their  schedules.  For  larger  assignments,  parts 
of  the  design  and  code  are  given  by  the  instructor. 

Some  amount  of  class  time  and  lab  time  is  devoted 
to  discussing  the  assignments.  The  executable 
solution  of  each  assignment  is  made  available  before 
the  due  date.  This  enables  the  students  to  understand 
the  input  and  output  format.  The  students  can  also 
test  the  performance  of  their  program  on  certain 
input  data  and  compare  it  against  the  instructors’ 
solution.  After  the  assignment  is  due,  the  solution  of 
the  assignment  is  shown  to  the  student,  and  the 
design  and  code  are  discussed. 

The  laboratory  exercises  are  conducted  in  a  closed 
laboratory  environment.  A  lab  manual3  which  has 
exercises  based  on  the  text  and  class  material  is 
made  available.  The  objective  of  each  of  the 
exercises  is  explained  first  and  then  the  students  are 
allowed  to  complete  the  work.  The  first  few  lab 
exercises  familiarize  the  student  with  the  operating 
system  and  the  Ada  compilation  environment.  Most 
of  the  other  lab  exercises  consist  of  incomplete  or 
incorrect  programs  which  the  students  have  to 
complete,  correct  or  enhance. 

1  Conclusions 

The  GS1  course  was  taught  by  the  author,  using  the 
above)  syllabus,  for  the  first  time  in  Fall  1992.  The 
author  has  taught  the  course  many  times  in  Pascal 
and  he  observed  that  the  software  engineering/ Ada 
combination  led  to  better  solution  designers. 
Enforcing  the  completion  of  design  before  starting 
code  helped  the  students  understand  the  solution 
process 'much  better.  They  were  able  to  find  more 
flaws  in  the  design.  The  modular  design  and 
development  helped  them  to  quickly  find  problem 
areas  and  fix  them.  The  closed  lab  environment 
definitely  helped  the  students  in  reinforcing  the 


concepts  learned  in  the  classroom.  The  number  ol 
assignments  may  be  reduced  by  one  or  two  by 
combining  concepts.  The  CS2  course  based  on  this 
approach  of  CS1  is  currently  under  preparation. 
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Abstract 

The  demands  of  the  marketplace  are  causing 
some  Computer  Science  programs  to  change  their 
main  teaching  language  from  Pascal  to  either  Ada 
or  C.  This  paper  discusses  the  strengths  and  weak¬ 
nesses  of  the  two  languages  in  an  educational  con¬ 
text.  The  goals  of  software  engineering  and  general 
pedagogical  concerns  are  used  to  structure  the  dis¬ 
cussion.  Availability  of  materials  and  student  atti¬ 
tudes  towards  the  languages  are  also  discussed. 

1.  Introduction 

The  choice  of  a  language  in  a  Computer  Sci¬ 
ence  program  has  broad  implications  for  teachers 
and  students.  This  paper  discusses  the  pros  and 
cons  of  Ada  versus  C  as  a  language  for  computer 
science  education.  The  context  of  the  paper  is  the 
initial  core  of  courses  in  the  curriculum  (usually  re¬ 
ferred  to  as  CSl,  CS2,  and  Data  Structures),  Both 
languages  offer  features  that  make  them  possible 
choices  as  the  support  language  across  the  curricu¬ 
lum.  The  dominance  of  Pascal  as  the  language  of 
choice  in  these  courses  has  declined.  The  main  com¬ 
petitors  of  Pascal  for  class  use  are  now  Ada  and  C, 
with  some  usage  of  C++,  Smalltalk,  and  Lisp.  The 
marketplace  has  never  used  Pascal  much,  but  has 
consistently  supported  C  and  Ada.  This  has  lead  to 
the  use  of  these  languages  in  many  schools,  either 
as  the  main  language  or  at  least  as  an  optional  lan¬ 
guage.  Both  languages  have  been  used  for  medium 
and  large  commercial  and  research  projects. 

When  evaluating  languages  for  course  use,  it 
is  important  to  keep  in  mind  the  main  goals  of 
a  Computer  Science  curriculum.  The  ACM/IEEE 
Curriculum  Recommendations1  offer  several  alter¬ 
native  program  goals.  We  believe  that  the  most 


important  goals  are  to  produce  students  who  are 
both  problem  solvers  and  communicators,  rather 
than  simply  coders.  To  this  end,  the  software  engi¬ 
neering  goals  and  principles  are  used  as  a  basis  for 
the  comparison  of  the  languages. 

Some  of  the  issues  to  be  considered  when  eval¬ 
uating  programming  languages  for  instructional 
purposes  arc: 

(1.)  how  difficult  is  the  language  to  learn/teach? 
(2.)  does  the  language  encourage  good  practices 
and  discourage  poor  practices? 

(3.)  is  the  language  easy  to  use? 

(4.)  does  the  language  inspire  or  dampen  enthusi¬ 
asm? 

In  each  of  these  matters,  while  worthwhile  re¬ 
sults  are  often  difficult  to  achieve  in  computer  sci¬ 
ence  education  as  with  other  aspects  of  life,  to  what¬ 
ever  extent  the  language  assists  the  student  and 
the  instructor,  those  positive  results  become  more 
likely  to  occur. 

In  addition  to  discussing  features,  there  is  a 
brief  discussion  of  the  availability  of  texts,  compil¬ 
ers,  and  other  resources,  and  of  how  the  languages 
are  perceived  by  students. 

2.  Comparison  of  Features 

Ada  and  C  have  many  similar  features.  Sim¬ 
ple  variable  types,  control  constructs,  function  and 
procedure  parameters  and  scoping,  and  structured 
data  types  are  different  in  the  details  in  the  two 
languages,  but  alike  enough  for  teaching  purposes. 
Important  differences  exist,  however,  on  a  number 
of  issues.  Following  Booch  a,  the  goals  and  princi¬ 
ples  of  software  engineering  are  used  to  illustrate 
these  differences. 
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The  following  four  concepts  are  given  by  Booch 
as  the  goals  of  software  engineering:  understand- 
ability,  reliability,  modifiability,  and  efficiency.  The 
principles  of  software  engineering  that  allow  these 
goals  to  be  met  are  discussed  below. 

Ureter*  taretefclllty 

Quite  often,  beginning  programming  students 
(and  advanced  students  also)  enjoy  the  challenge 
of  communicating  in  the  somewhat  alien  language 
understood  by  computers.  If  they  enjoyed  writ¬ 
ing  clear  English  prose  more  than  technical  jargon, 
they  would  probably  major  in  one  of  the  humanistic 
studies  rather  than  computer  science.  It’s  not  an 
accident  that  the  descriptive  phrase  used  is,  “play¬ 
ing  with  the  computer.” 

By  using  a  high-level  language  which  approx¬ 
imates  English  prose,  a  student  is  removed  from 
the  alien  feeling  of  having  to  think  at  the  machine 
level.  Student  are  given  the  tools  and  language  to 
communicate  meaning  and  intentions  to  whomever 
is  reading  and  maintaining  code.  Writing  readable 
code  is  encouraged. 

Ada  is  sufficiently  readable  (with  careful  choice 
of  identifiers)  to  be  mostly  self-documenting,  com¬ 
ments  being  used  primarily  to  explain  the  non-ob- 
vious.  Comments  can  be  a  two-edged  sword  in  code 
with  a  long  lifetime;  if  a  maintenance  program¬ 
mer  does  not  also  modify  documentation  to  meet 
changes  in  code,  the  documentation  becomes  incor¬ 
rect 

The  sometimes  obscure  syntax  of  C  can  add  ad¬ 
ditional  layers  of  complexity  to  the  problem-solving 
activity.  C  code  can  suffer  without  discipline  by 
the  programmer,  since  C  is  not  inherently  self-doc¬ 
umenting.  Many  examples  exist  of  C  statements 
which  even  an  experienced  C  programmer  would 
find  difficult  to  decipher.  This  often  involves  point¬ 
ers,  arrays,  and  functions,  such  as  int  *(*f)(int)  To 
some  extent,  C  programmers  consider  this  kind  of 
code  as  a  badge  of  honor.  Instructors  should  not  en¬ 
courage  this  kind  of  code,  of  course.  Similarly,  weak 
typing  in  C  allows  variables  to  change,  chameleon¬ 
like,  from  one  type  to  another  at  the  programmer’s 
whim. 

At  a  higher  level,  the  data  structures  and  mod¬ 
ules  of  a  program  must  be  easily  understood.  If  you 
can’t  understand  the  problem  and  the  solution  in 
terms  of  the  problem  (i.e.  at  the  abstract  level)  you 


can’t  hope  to  be  able  to  understand  the  solution  at 
the  implementation  level.  Abstraction  allows  stu¬ 
dents  to  focus  on  problem-solving,  rather  than  the 
details  of  the  implementation. 

Both  languages  have  facilities  needed  to  build 
custom  data  types  and  to  modularize  programs. 
Logical  data  types  such  as  linked  lists  and  trees 
can  be  built  in  most  structured  languages,  how¬ 
ever,  and  is  not  discussed  further.  Modularity  is 
handled  somewhat  differently  in  each  language. 

For  example,  C  does  not  allow  nesting  of  func¬ 
tions,  while  Ada  does.  In  C,  a  function  called  only 
from  inside  one  function  is  still  visible  to  other  func¬ 
tions  rather  than  being  private.  Ada  allows  proce¬ 
dures  to  be  nested,  so  that  modularity  and  need-to- 
know  inforamtion  hiding  is  achieved. 

Functions  can  be  grouped  into  files  for  sepa¬ 
rate  compilation  in  both  languages.  Typically,  C 
function  prototypes  are  placed  in  a  header  file  that 
is  included  by  other  modules.  Ada  uses  an  inter¬ 
face  definition  for  a  module.  The  mechanics  are 
different,  but  the  effect  is  the  same. 

C  can  provide  a  measure  of  information  hiding 
through  the  use  of  separate  compilation  modules. 
Header  files  provide  function  prototypes  and  vari¬ 
able  type  information  to  other  modules.  The  de¬ 
tails  of  the  data  structures  themselves  can  be  kept 
withir.  the  modules.  Abstract  data  types  are  sim¬ 
ulated  through  the  use  of  pointers  to  data  struc¬ 
tures  and  providing  only  those  prototypes  neces¬ 
sary  to  manipulate  those  data  structures.  How¬ 
ever,  since  the  pointer  can  be  used  to  access  the 
data  structure’s  components,  and  the  components 
can  be  found  in  the  header  file,  true  data  abstrac¬ 
tion  is  not  possible. 

Polymorphic  data  structures  (those  that  are 
type-independent)  are  possible  in  C  by  using  void 
pointers.  Code  that  operates  on  such  structures 
cannot  use  on  any  data  stored  in  the  structures. 
This  is  not  enforced  by  C  but  relies  on  programmer 
discipline. 

In  Ada,  one  can  easily  construct  abstract  data 
types  using  packages,  sr’ving  the  information  hid¬ 
ing  problem.  Only  the  public  interface  is  accessable 
by  calling  routines;  private  procedures  and  data 
types  are  not  accessable.  ADTs  are  one  step  away 
from  objects. 

Polymorphism  is  handled  in  a  different  way  in 
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Ada,  using  generic  packages  and  instantiation  in 
the  appropriate  data  type. 

There  are  no  inherent  restrictions  on  whether 
the  functions  in  a  C  compilation  module  are  related 
to  one  another.  The  cohesion  of  the  module  is  left, 
to  the  programmer.  Likewise,  different  modules 
may  be  related  to  each  other  by  functionality  or  by 
data  structures  if  the  programmer  chooses,  allow¬ 
ing  a  high  degree  of  coupling.  In  Ada,  packages 
provide  a  natural  structure  for  encapsulating  log¬ 
ically  related  types  and  subprograms.  The  use  of 
packages  encourages  logical  structuring,  but  as  in 
C,  there  is  no  enforcement  ofhigh  module  cohesive¬ 
ness  or  low  intermodule  coupling.  Since  these  are 
design  issues,  an  instructor  must  enforce  appropri¬ 
ate  standards. 

RollablHty 

Ensuring  that  a  program  can  prevent  and/or 
recover  from  errors  is  a  key  to  producing  quality 
software.  Overall  software  quality  assurance  is 
probably  beyond  the  scope  of  the  first  few  program¬ 
ming  courses,  but  several  important  issues  should 
be  covered. 

Type  checking  can  ensure  that  certain  types 
of  errors  are  prevented.  C  has  weak  type  checking. 
For  example,  an  enum  (enumerated)  type  is  treated 
as  an  integer,  so  that  an  enumerated  variable  can 
be  passed  in  place  of  an  integer  parameter.  Since  C 
compilers  allow  this,  the  lint  precompiler  must  be 
used  to  detect  it.  C  also  lacks  the  ability  to  declare 
subrange  types.  Out  of  bounds  errors  can  easily 
occur,  as  in  array  references.  Promotion  of  numeric 
data  types  within  expressions  is  often  automatic, 
using  a  progression  from  integer  to  float  to  double. 
Manual  promotion  i3  also  possible,  as  in  (floai)i. 

Ada  has  strong  typing.  There  are  several  con¬ 
sequences  of  this  fact:  (1.)  Safer  code.  The  sys¬ 
tem  catches  faulty  data  and  informs  student  rather 
than  using  the  data  in  calculations,  making  code 
easier  to  debug.  This  requires  clear  thinking  re¬ 
garding  appropriate  data  types  and  allowable  op¬ 
erations.  (2.)  More  thinking  about  design  and  data 
types  is  required  before  coding.  (3.)  Programs  can 
be  more  tedious  to  write  because  of  (2).  (4.)  Type 
checking  across  compilation  units  assists  in  build¬ 
ing  modular  code  which  can  be  integrated  readily. 
Monolithic  code  is  inherently  more  difficult  to  de¬ 
bug. 


Exception  handling  is  provided  in  C  by  includ¬ 
ing  the  ermo  and  signal  header  files.  Usage  of  error 
codes  and  signals  is  rather  esoteric  and  is  usually 
omitted  from  beginning  courses. 

Exception  handling  is  used  frequently  in  Ada 
and  is  quite  helpful  in  finding  source  of  errors.  Pre¬ 
defined  exceptions  are  readily  caught  by  the  sys¬ 
tem,  and  students  have  options  in  handling  excep¬ 
tions.  Compilers,  though,  could  be  more  helpful  in 
giving  details  of  conditions  under  which  exceptions 
were  raised. 

Modlflabt'.ty 

Modifications  to  code  must  have  only  small,  lo¬ 
cal  effects  -  “controlled  change”,  as  Booch  says.  The 
key  to  controlled  change  is  structured,  modular  de¬ 
sign.  Almost  any  modem  programming  language 
supports  structured  programming  and  modularity. 
As  noted  above,  C  does  not  allow  nesting  of  func¬ 
tions;  all  functions  are  at  the  same  level.  Modules 
-  separate  compilation  units  -  are  supported. 

Several  factors  limit  the  effects  of  nr  ,dularity 
in  C.  The  fact  that  global  variables  are  allowed  is 
naturally  an  inhibitor  to  controlled  change.  Vari¬ 
ables  may  be  global  to  a  program  by  placing  them 
in  a  header  file  or  by  declaring  them  as  external, 
or  may  be  global  only  to  the  module  that  they  are 
declared  in. 

In  Ada,  modularity  is  enhanced  by  packages 
and  facilities  for  separate  compilation.  By  devel¬ 
oping  the  specification  for  a  package  and  delay¬ 
ing  consideration  of  the  body’s  implementation,  the 
student  can  concentrate  on  problem  solving.  This 
in  turn  supports  top-down  design. 

Effldeney 

There  are  several  interpretations  of  efficiency. 
The  one  most  often  used  is  time  related:  speed  of 
execution.  A  second  is  space  related:  size  of  data 
structures  and  overall  code.  The  trade-offs  between 
these  tw';  are  usually  discussed  in  the  Data  Struc¬ 
tures  and  Algorithms  course(s).  A  third  meaning  is 
left  to  Software  Engineering:  efficiency  of  the  de¬ 
velopment  cycle.  This  is  related  both  to  the  ease 
of  program  development  and  to  the  ability  to  reuse 
code. 

Students  often  become  overly  concerned  with 
the  efficiency  of  code,  sometimes  focusing  on  at¬ 
tempts  to  achieve  marginal  increases  in  speed  or 
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savings  in  memory  at  the  expense  of  more  impor¬ 
tant  goals  such  as  understandability  or  modifiabil¬ 
ity.  Recognizing  the  commonly  applicable  “90-10 
Rule"  (90%  of  execution  time  is  spent  in  executing 
10%  of  the  code)  the  student  can  perhaps  be  per¬ 
suaded  to  isolate  the  expensive  10%  of  the  code, 
and  concentrate  on  optimizing  that  without  sacri¬ 
ficing  other  desirable  traits  of  the  remaining  90%. 
The  modularity  features  and  adherence  to  inter¬ 
faces  of  Ada  units  provide  powerful  support  for  this 
approach. 

On  the  other  side,  sometimes  instructors  tend 
to  lose  sight  of  the  importance  of  making  efficient 
use  cf  the  student’s  time,  energy,  and  enthusiasm. 
Programming  assignments  should  ideally  be  de¬ 
signed  so  that  they  challenge,  without  overwhelm¬ 
ing,  the  student.  There  should  not  be  an  excess  of 
tedious  detail  to  blur  the  new  concepts.  The  strong 
typing  of  Ada  often  seems  tiresome  at  fir*t,  but 
for  understandability  and  reliability,  that  is  prefer¬ 
able  to  the  weak  typing  in  C  which  allows  vari¬ 
ables  to  change  from  one  type  to  another.  When 
you  violate  the  rules  in  Ada,  the  compiler  informs 
you  forthrightly.  If  you  unintentionally  violate  the 
rules  in  0,  the  compiler  proceeds  blithely,  and  you 
may  have  no  idea  that  your  results  are  meaning¬ 
less,  or  why. 

The  greater  reusability  of  Ada  code  encourages 
and  supports  the  building  of  modules  which  can 
readily  be  incorporated  into  larger  systems.  Such 
systems  can  approximate  applications  in  the  “real” 
world  more  closely  than  typical  programming  as¬ 
signments. 

Code  reuse  in  C  is  accomplished  via  libraries. 
Related  functions  can  be  gathered  together  in  a 
module,  then  compiled  and  stored  as  a  binary  mod¬ 
ule.  C  handles  many  simple  tasks  by  this  method 
rather  than  including  language  primitives.  There 
are  libraries  for  mathematics,  string  operations, 
and  file  operations,  among  others.  Users  can  create 
their  own  libraries  and  often  do  -  for  vector  func¬ 
tions,  image  and  signal  processing,  and  so  on.  The 
amount  of  reuse  of  these  libraries  is  low,  however, 
with  users  forced  to  write  their  own  libraries  if  a 
source  cannot  be  found. 

Software  components  in  Ada  can  be  re-used 
on  several  levels:  (1.)  Code  can  be  supplied  to  a 
student  to  use  in  application.  (2.)  Students  can 


develop  modules  to  be  used  as  basis  for  ultimately 
larger  systems.  (3.)  Maintainable  code  can  be  mod¬ 
ified  (or  even  made  generic)  to  relieve  the  tedium 
of  doing  “the  same  stuff  with  only  a  few  modifica¬ 
tions.”  This  is  especially  helpful  in  the  Data  Struc¬ 
tures  course. 

While  not  appropriate  for  students  to  design 
and  write  in  CS1,  simple  generic  units  can  be  pro¬ 
vided  for  the  students  to  use.  This  promotes  think¬ 
ing  in  terms  of  abstractions  and  about  common 
properties  and  algorithms. 

3.  Instructional  Concerns 

The  difficulty  of  teaching  a  language  depends, 
of  course,  on  the  audience.  Experienced  program¬ 
mers  have  a  context  within  which  to  place  new 
ideas;  conversely,  some  old  ideas  may  need  to  be 
unlearned.  For  a  beginning  language,  one  would 
hope  to  encourage  good  habits  and  discourage  bad 
ones. 

The  basic  constructs  of  each  language  are  quite 
similar.  Variable  declarations,  looping,  decisions, 
and  procedures  are  handled  similarly.  A  number  of 
differences  have  been  discussed  previously;  several 
more  are  offered  here. 

Input/output  is  complicated  in  Ada  by  the  need 
to  instantiate  generic  I/O  packages.  For  beginners, 
the  instructor  needs  to  provide  an  “Easy.IO”  pack¬ 
age  to  ease  this.  C’s  I/O  is  more  straightforward 
for  beginners.  There  are  simple  formatting  rules 
for  all  types,  provided  the  stdio  header  is  included, 
that  allow  I/O  without  too  much  effort. 

Parameter  passing  in  C  is  complicated  by  the 
pointer  notation.  Rather  than  Ada’s  designations  of 
out  toTetum  values,  C  requires  that  a  variable’s  ad¬ 
dress  be  passed  using  the  &  operator  and  received 
using  the  *  de-referencing  operator.  When  com¬ 
bined  with  the  need  to  pass  variables  that  are  al¬ 
ready  pointers  (as  in  linked  list  processing),  this  is 
quite  cumbersome.  Ada  allows  any  type  of  variable 
to  be  passed  -  -  record,  multi-dimensional  array, 
access  types,  private  types,  or  even  task  types.  Ac¬ 
cess  types  provide  dynamically  created  variables, 
similar  to  C  pointers  but  strongly  typed. 

While  it  is  possible  to  write  cryptic  code  in  any 
language,  C  has  the  reputation  of  encouraging  such 
code.  Programmer  discipline  is  needed  more  than 
in  Ada  to  write  clear,  concise,  modular  code. 
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4.  Availability 

The  availability  of  Ada  texts  is  no  longer  the 
concern  it  was  previously.  Introductory  texts  and 
data  structures  texts  are  now  widely  available,  as 
are  a  fair  number  of  Software  Engineering  books 
using  Ada.  The  Ada  Information  Clearinghouse 
provides  a  listing  of  current  Ada  books  (over  130  in 
the  latest  list).  The  Catalog  of  Resources  for  Ed¬ 
ucation  in  Ada  and  Software  Engineering  3,  also 
from  the  Ada  IC,  is  a  list  of  courses  offered  in  Ada 
at  colleges  and  universities.  Books  using  C  are  also 
readily  available.  For  other  courses,  though,  nei¬ 
ther  language  is  commonly  used.  Ada  continues  to 
suffer  from  the  scarcity  of  affordable,  easy  to  use 
compilers  and  PC  environments.  There  are  several 
PC  Ada  compilers  available.  There  is  a  freeware 
Ada  interpreter  for  workstation  environments,  and 
a  freeware  Ada  compiler  will  be  available  soon.  C  is 
normally  the  default  language  in  workstation  envi¬ 
ronments,  so  compilers  are  normally  included  with 
the  system  software.  There  are  a  number  of  popu¬ 
lar  PC  compilers  for  C  that  are  affordable  for  stu¬ 
dents. 

S.  Student  Perspectives 

A  small  group  of  students  who  had  experience 
in  both  Ada  and  C  were  interviewed  on  their  views 
of  the  languages.  Despite  the  small  sample,  several 
interesting  points  were  made. 

Overall,  Ada  programs  were  easier  to  read. 
Programmer  discipline,  the  students  realized,  was 
a  key  to  writing  readable  C  programs.  This  was 
also  true  of  other  goals,  such  as  modularity,  tight 
interfaces,  and  type  checking.  In  C,  most  of  the 
students  could  not  overcome  their  desire  to  use  un¬ 
derlying  data  type  when  using  enum  variables,  for 
example.  In  fact,  while  Ada’s  strong  typing  was 
seen  as  an  overall  advantage,  most  found  it  some¬ 
what  confining. 

There  was  general  agreement  that  packages 
and  generics  were  a  powerful  tool  in  Ada  that  C 
could  not  match.  The  resulting  modularity  of  their 
programs  was  cited  as  an  important  factor  in  de¬ 
signing  programs.  In  addition,  focusing  on  the 
procedure/package  specifications  made  it  easier  to 
handle  information  hiding. 

Exception  handling  was  superior  in  Ada.  Since 
it  is  an  inherent  part  of  the  language,  all  the  stu¬ 


dents  used  it  and  felt  comfortable  doing  so,  real¬ 
izing  that  they  were  writing  mo-e  reliable  code. 
Input  and  output  were  rated  as  somewhat  difficult 
in  Ada,  at  least  for  beginners.  In  C,  it  was  easier 
to  format  output  data  without  worrying  about  in¬ 
stantiating  I/O  packages.  After  the  students  had 
more  experience  with  generics,  this  was  less  of  a 
problem. 

C  was  regarded  as  a  more  “powerful”  language 
than  Ada.  This  misperception  related  to  being  able 
to  handle  low-level  programming,  such  as  device 
manipulation,  in  C  but  not  in  Ada.  This  kind  of  pro¬ 
gramming  is,  in  fact,  possible  in  either  language. 
Pointers  were  also  noted  as  a  powerful  feature,  but 
the  steep  learning  curve  to  manipulate  C  pointers 
correctly  was  mentioned. 

6.  Conclusions  | 

i 

When  comparing  programming  languages,  per¬ 
sonal  preference  plays  a  large  part.  In  determining 
what  language  to  use  to  implement  a  project,  the 
presence  or  absence  of  special  features  may  be  criti¬ 
cal  to  efficient  implementation,  or  even  to  the  possi¬ 
bility  of  implementation.  For  instruction  purposes, 
though,  there  are  different  considerations.  This  pa¬ 
per  presented  some  ideas  relevant  to  instructional 
languages  from  a  software  engineering  framework. 

There  are  several  advantages  of  Ada  over  C  as 
a  teaching  language.  That  C  requires  programmer 
discipline  to  achieve  similar  effects  as  Ada  shows 
that  Ada  is  the  more  natural  language  for  use  in 
instruction.  Self-documentation,  an  emphasis  on 
modularity,  and  greater  reuse  of  code  are  all  ad¬ 
vantages  of  Ada. 

So  why  choose  C?  Marketplace  pressures  en¬ 
sure  its  survival,  but  that  is  not  enough  to  choose 
it  as  a  teaching  language. 
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Abstract 

This  paper  presents  an  integrated  envi¬ 
ronment  that  is  under  development  at  the 
University  of  Wales,  Aberystwyth,  with  the 
specific  goal  of  supporting  the  teaching  of 
software  engineering1.  The  environment 
presents  users  with  a  fully  integrated  tool 
set  that  addresses  many  aspects  of  the 
software  life  cycle.  To  a  large  extent,  the 
environment  has  been  developed  through 
the  reuse  of  existing  software. 

The  paper  is  divided  into  two  parts.  First, 
the  technical  details  are  presented  This  is 
followed  by  a  discussion  of  the  educational 
aspects  of  the  environment,  its  application 
to  a  number  of  different  courses,  and  an 
evaluation  of  experiences  to  date. 

1  Introduction 

Software  Engineering  is  a  common  theme 
running  through  all  of  the  courses  offered 
by  the  Computer  Science  Department  at 
the  University  of  Wales,  Aberystwyth; 
it  is  evident  in  the  emphasis  placed 
on  design,  quality  assurance  and  project 
management.  The  introduction,  in  1986, 
of  Ada  as  the  main  programming  language 
has  enabled  students  to  apply  some  of  the 
design  principles  that  they  learn,  but  the 
lack  of  specific  support  software  still  makes 

1  Parts  of  this  p>per  have  previously  appeared  in 
an  article  [1]  in  the  Software  Engineering  Journal 
and  are  reproduced  bets  by  kind  permission  of  the 
editors. 


it  difficult  for  them  to  practise  everything 
they  are  taught. 

The  environment  being  developed  by  the 
Software  Engineering  Research  Group  at 
Aberystwyth  is  capable  of  supporting  most 
of  the  software  development  process.  It 
will  eventually  provide  students  with  tools 
to  support  design,  coding,  project  manage¬ 
ment,  document  production,  verification, 
validation  and  testing. 

The  environment  b  far  more  than  a 
collection  of  integrated  CASE  tools  [2]. 
It  has  been  designed  to  be  used  in  a 
way  which  demonstrates  many  of  the 
concepts  of  software  engineering  in  a 
practical  and  educational  manner.  For 
this  reason,  it  is  known  as  the  TIPSE,  an 
Integrated  Project  Support  Environment 
for  Teaching. 

Users  of  the  TIPSE  are  able  to  experience 
first  hand  the  benefits  to  be  gained  from  us¬ 
ing  and  developing  software  within  a  fully 
integrated  environment;  an  environment 
that  is  currently  integrated  at  the  level 
of  database  and  user  interface  but  which 
will  be  ultimately  integrated  at  the  level  of 
process. 

The  current  release  of  the  TIPSE  is  already 
being  used  by  students  and  its  effectiveness 
evaluated.  1+  is  intended  that  new  tools 
will  be  added  and  existing  ones  enhanced 
until  the  TIPSE  becomes  suitable  for 
use,  not  ouly  for  undergraduate  students, 
but  also  for  participants  on  advanced 
software  engineering  courses.  To  satisfy  the 
different  experience  levels  of  its  users,  all 
releases  of  the  TIPSE  will  have  separate 
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modes  of  operation  for  both  naive  paid 
sophisticated  users  alike.  The  system 
is  inherently  multi  user  because  of  the 
need  to  provide  effective  support  for  group 
project  work. 

2  An  integrated  approach 

The  widespread  adoption  of  stri’.ctured 
methods  by  software  engineers  together 
with  the  increased  availability  of  compara¬ 
tively  cheap  powerful  workstations  has  lead 
to  a  proliferation  of  CASE  tools  available 
on  the  market.  Although  there  are  now 
tools  to  assist  in  almost  all  aspects  of 
software  development,  few  address  more 
than  a  very  limited  number  of  stages  within 
the  software  lifecycle.  Consequently  a 
typical  user  will  have  access  to  several 
different  CASE  tools  working  on  several 
different  platforms.  The  transfer  of  data 
from  one  ~ool  to  another  is  often  difficult 
and  maintaining  consistency  between  the 
different  tools  is  alrocat  impossible. 

The  idea  of  supporting  tool  interworking 
is  certainly  not  new.  In  1980,  the 
Stoneman  Report  [3]  promoted  the  idea 
of  using  a  project  database  to  hold  the 
products  of  the  software  development 
process.  Such  a  database  would  be 
all  encompassing,  storing  everything  from 
project  plans  &nd  initial  specifications 
through  to  abject  modules  and  test  data 
sets.  The  relationships  between  the  objects 
would  also  be  captured  and  tools  would 
only  be  able  to  access  the  information  via 
the  database.  Over  the  last  ten  years, 
much  work  has  been  undertaken  in  this 
area  particularly  by  the  two  international 
tool  support  interface  projects  PCTE  [4] 
and  CAIS  [5,  6}.  The  need  for  a  tool 
support  interfaces  is  now  widely  accepted 
and  forms  the  basis  for  our  development  of 
the  TirSE. 

Integration  at  the  level  of  the  database  is 


just  one  facility  provided  by  the  TIPSE. 
Consistency  of  interaction  of  all  tools  with 
the  user  is  t  very  powerful  integrating 
principle.  Users  should  be  able  to  move 
from  one  tool  to  another  without  having 
to  familiarise  themselves  with  alternative 
methods  of  interaction.  It  is  not  desirable 
for  users  to  undergo  retraining  every 
time  a  new  tool  ic  provided  within  an 
environment,  indeed  this  principle  should 
apply  not  only  to  different  versions  of 
a  particular  tool  bat  also  to  completely 
different  tools.  Although  this  is  important 
in  all  environments,  it  is  particularly 
relevant  from  a  teaching  perspective. 
Obvioucly  a  graphical  design  editor  and 
an  Ada  compiler  cannot  present  identical 
interfaces  to  the  user,  but  the  ‘principle  of 
minimum  surprise’  should  hold;  in  other 
words,  the  same  user  ac  tion  should  have 
predictably  similar  effects  within  different 
tools.  This  means,  for  example,  that  menu 
selection  should  always  be  done  in  the  same 
way  and  that  users  of  the  tools  should 
not  be  presented  with  different  styles  of 
user  interface  by  different  tools.  MicroSoft 
Windows  3  is  an  excellent  example  of  an 
environment  which  exploits  this  principle 
very  etl’ectively. 

There  is  an  increasing  interest  in  the  role 
of  process  modeling  as  a  third  axis  of 
integration  (see  [7]  for  example).  Just 
how  far  this  is  appropriate  in  a  teaching 
environment  is  something  that  we  are 
currently  investigating. 

3  Foundations  of  the  envi¬ 
ronment 

The  Software  Engineering  Research  Group 
at  Aberystwyth  first  began  work  in  the 
area  of  integrated  support  environments 
back  in  1984  as  a  partner  in  the 
Ai/ey  Eclipse  consortium  [8].  The 
second  generation  IPSE  produced  by  this 
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consortium  haa  since  been  developed  and 
exploited  commercially  by  IPSYS  Software 
pic,  in  the  form  of  the  Tool  Builder’s  Kit 
(TBK)  [9].  The  influence  of  a  related 
project,  PCTE  (Portable  Common  Tools 
Environment)2,  can  be  seen  dearly  in  the 
development  of  Eclipse  and  has  been  an 
important  consideration  within  the  TIPSE. 

Initial  ideas  ahou*  the  TIPSE  were 
strengthened  by  our  experiences  on  the 
ESPRIT  funded  DRAGON  project  [10]  in 
which  we  developed  a  prototype  structure 
editor  capable  of  supporting  both  textual 
and  diagrammatic  views  of  a  program  from 
a  single  underlying  data  structure. 
Throughout  our  collaborative  efforts,  one 
unifying  theme  has  beer  that  of  software 
reuse.  It  is  not  surprising  therefore  that  the 
TIPSE  is  being  developed  as  far  as  possible 
through  the  reuse  of  existing  components. 

At  the  heart  of  the  TIPSE  lies  the  TBK 
tool  support  interface.  It  consists  of 
libraries  of  generic  facilities  which  we 
have  used  to  implement  our  tools.  Tools 
produced  in  this  way  are  normal  Unix 
tools  which  coexist  with  all  other  Unix 
tools.  All  of  these  tools  present  a  common 
user  interface  and  share  common  database 
access  procedures,  so  enabling  a  high 
degree  of  integration.  Though  the  current 
release  of  the  TBK  is  stand  alone,  a 
decision  has  been  made  that  future  releases 
of  the  TIPSE  will  be  available  on  the 
Emeraude  implementation  of  PCTE. 

Fig.  1  illustrates  the  main  component  parts 
of  the  TIPSE. 

Integration  through  the  database 

The  TBK  database  at  the  centre  of 
the  TIPSE  closely  follows  the  entity- 
relationship-attribute  model  of  PCTE.  Un¬ 
like  relational  database  implementations 

*PCTE  hu  been  recently  accepted  a*  an  ECMA 
(European  Computer  Manufacturer*  Association) 
standard  for  CASE  tools. 


which  simply  record  details  of  software 
products  held  within  a  conventional  file 
store,  the  entity  model  actually  stores 
the  objects  within  the  database  itself. 
Specifications,  source  code  objects  and 
even  program  libraries  are  all  held  as 
individual  database  entities.  The  links 
between  these  objects,  for  example  those 
which  exist  between  an  object  specification 
and  its  implementation,  are  stored  as 
actual  links  within  the  database. 


A  further  advantage  of  adopting  the  PCTE 
model  is  the  strong  typing  that  it  provides. 
Through  the  object  management  system 
(OMS),  the  user  is  able  to  define  and 
manipulate  objects  but  only  in  strict 
accordance  with  the  rules  defined  for  the 
particular  object  types.  These  rules, 
that  is  the  properties  of  the  information 
types,  are  defined  in  the  form  of  schema 
definition  sets  which  are  used  at  run¬ 
time  to  enable  visibility  over  the  database. 
As  will  be  described  later,  these  schema 
definition  sets  ere  fundamental  to  the 
provision  of  multiple  views  and  the  support 
of  incrementality  within  the  TIPSE. 


As  a  refinement  on  top  of  the  PCTE  data 
model,  the  database  provided  by  TBK 
permits  a  fine  grain  definition  of  objects 
in  the  form  of  a  second  tier.  In  this  way  it 
is  possible  to  detail  the  contents  of  certain 
object  types;  Ada  source  code  might  be 
stored  in  the  form  of  a  syntax  tree,  for 
example.  Similarly  an  object  at  the  first 
tier  might  be  defined  as  a  deliverable 
document;  the  second  tier  definition  of  such 
an  object  then  defines  the  structure  of 
its  contents,  the  breakdown  of  individual 
chapters  into  sections  and  paragraphs. 
Facilities  for  accessing  and  manipulating 
the  objects  at  both  levels  are  provided 
through  a  single  unifying  interface. 
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Figure  1:  The  TIPSE  architecture 


Integration  through  the  user  inter* 

face 

The  second  axis  of  integration  within  the 
TIPSE  is  that  of  the  user  interface.  All 
of  the  tools  interact  with  the  user  through 
a  set  of  high  level  interfaces  provided 
by  TBK.  These  interfaces  ensure  that  a 
consistent  user  interface  is  provided  in  a 
device  independent  way. 

The  power  of  the  user  interface  is  achieved 
by  separating  the  front  end  from  the  rest 
of  the  tool.  This  idea  is  based  on  the 
philosophy  that  a  tool  simply  supplies  and 
demands  information  to  and  from  the  user; 
it  need  not  be  concerned  with  how  this 
information  is  handled.  For  example  where 
a  tool  wishes  the  user  to  select  a  value  from 
a  set  of  possible  values,  the  user  might 
be  asked  to  choose  from  a  menu  with  all 
options  on  display,  cycle  through  a  set  with 
one  at  a  time  on  display,  or  type  a  value 
which  is  then  checked  for  existence  in  the 
permitted  set. 

To  achieve  this  separation,  calls  to  the 
interface  components  are  not  hard  coded 


into  program  code  as  one  might  expect. 
Instead,  the  interaction  style  and  layout  of 
all  tools  produced  using  TBK  is  described 
by  means  of  the  ‘Format  Definition 
Language’  (FDL).  Using  this  language,  the 
tool  builder  is  able  to  give  a  specification 
detailing  layout  and  functionality  of  the 
user  interface.  FDL  does  not  just  define  the 
static  appearance  of  a  tool;  it  is  also  used  to 
associate  operations  with  the  interface,  for 
example,  the  action  to  be  executed  when 
the  user  clicks  on  a  button. 

The  FDL  definitions  are  held  in  a  separate 
text  file  which  is  interpreted  on  execution 
of  the  tool.  As  the  tool  starts  up,  the 
required  user  interface  is  generated  as 
specified  by  the  FDL  definitions.  If  the 
programmer  is  unhappy  with  any  aspects 
of  the  user  interface,  the  FDL  definitions 
can  be  easily  altered  and  the  tool  re- 
invoked  to  show  the  new  leyout.  No 
recompilation  or  rebuilding  of  the  tool  is 
necessary.  These  dynamic  aspects  of  FDL 
make  the  user  interface  facilities  of  the 
TIPSE  very  powerful  and  enable  users 
within  the  environment  to  successfully 
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develop  tool  interfaces  in  a  very  short 
period  cf  time. 

The  high  level  user  interface  primitives 
have  been  implemented  to  run  under 
the  X  Window  system  [11].  This  is  a 
particularly  important  feature  as  it  enables 
the  environment  to  include  tools  which  run 
on  hardware  configurations  other  than  Sun 
work  stations,  the  original  environment 
of  the  TIPSE.  The  TIPSE  may  include 
software  which,  though  running  on  a  PC, 
interacts  with  the  user  sitting  at  the  Sun 
work  station.  Such  PC  applications  might 
be  supported  by  DOS  emulators  running 
on  the  work  stations.  It  is  expected 
that  a  number  of  project  management 
tools  including  Microsoft  Project  Will  be 
supported  in  this  way.  Whatever  method 
of  implementation  is  used,  as  far  as  the  user 
is  concerned,  all  of  the  tools  will  appear  to 
work  on  a  single  platform. 

4  The  meta-tools  -  build¬ 
ing  blocks  for  the  TIPSE 

The  generic  function  layer  of  TBK  (see 
fig  1)  provides  the  TIPSE  with  a  number 
of  powerful  meta-tools  which  we  havi  used 
to  generate  a  closely  integrated  tool  set. 

A  generic  design  editor  can  be  instantiated 
to  provide  diagramming  support  for  all 
aspects  of  software  engineering,  from 
simple  data  diagrams  to  more  complex  rep¬ 
resentations  used  by  a  structured  method. 
This  editor  not  only  provides  operations 
for  manipulating  diagrams,  but  also  checks 
that  the  design  conforms  to  the  rules  of 
the  method.  With  a  little  specialised 
customisation  by  the  tool  builder  a  very 
powerful  tool  can  be  produced. 

A  similar,  and  complementary  tool  to  the 
design  editor  is  the  generic  structure  editor. 
Both  tools  simply  present  to  the  user 
different  representations  of  objects  that  are 


held  within  the  database.  The  design 
editor  presents  a  graphical  view  of  these 
objects;  the  structure  editor  presents  a 
textual  view.  By  manipulating  the  on¬ 
screen  representation  of  an  object,  the  user 
is  actually  altering  the  database. 

These  meta-tools  have  been  used  to  build 
tools  in  a  fraction  of  the  time  normally 
required.  They  form  the  basis  of  a 
number  of  high  level  tools  many  of  which 
are  still  under  development,  that  will 
help  ensure  the  student  obtains  maximum 
benefit  from  using  such  an  environment. 
The  tools  that  are  available  in  the  current 
release  of  the  TIPSE  include  method 
support  tools  (including  diagrammatic  rep¬ 
resentation),  programming  support  tools 
(such  as  programming  language  structure 
editors),  version  control  and  basic  project 
management  tools. 

4.1  The  TIPSE  front  end 

The  facilities  offered  by  the  TIPSE  are 
all  accessed  through  a  centralised  control 
panel  which  has  a  similar  appearance  to  all 
of  the  other  tools  within  the  environment. 
In  addition  to  utilising  the  user  interface 
primitives,  this  uniformity  of  user  interface 
has  been  achieved  by  the  adoption  of  a 
standard  interaction  metaphor  The  TBK 
control  panel  idea  [8,  chapter  6],  follows  the 
analogy  of  an  interface  to  a  complex  piece 
of  hardware,  like  the  operator  panel  at  a 
power  station;  the  user  interface  provides 
interaction  possibilities  in  the  form  of 
buttons,  menus,  state  selectors,  indicator 
lights  and  signs.  The  similar  appearance 
of  the  two  tools  depicted  in  Figs  2  and  4 
demonstrates  this  consistency. 

In  support  of  an  incremental  philosophy 
adopted  by  the  TIPSE,  the  control 
panel  has  been  designed  to  offer  facilities 
dependent  upon  the  skill  levels  of  the 
student.  Initially  the  facilities  include  only 
basic  editing  operations  and  programming 
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Figure  2:  The  TIPSE  change  control  tool 


support  tools,  but  as  the  users  become 
more  experienced,  the  available  operations 
are  enriched  to  include  configuration 
control  and  project  management. 

The  TIPSE  as  a  programming 
environment 

Although  the  TIPSE  now  provides  tools 
to  support  many  different  stages  of  the 
software  development  process,  develop¬ 
ments  were  initially  directed  at  supporting 
programming.  Even  before  the  idea  of 
the  TIPSE  had  been  developed,  a  number 
of  research  projects  at  Aberystwyth  were 
already  providing  support  environments 
for  the  Ada  programming  language. 

The  most  significant  of  these  environments, 
DDT  [12],  developed  under  the  DRAGON 
project  [10],  supported  the  notion  of 
multiple  views.  Though  only  a  prototype, 
the  user  of  this  tool  was  able  to  textually 
specify  an  Ada  program  and  then,  for 
example,  request  a  graphical  view  to 
show  the  program’s  relationship  with  other 
library  units. 

The  idea  of  utilising  multiple  views  within 


a  structure  editor  has  been  fundamental 
to  the  design  of  our  current  tool  set. 
Currently  Ada  is  the  only  supported 
language,  but  developments  are  being 
planned  to  support  languages  such  as  C 
and  C++.  Fig.  3  shows  an  example 
invocation  of  the  editor,  for  a  partially 
developed  Ada  program. 

As  with  all  applications,  the  Bchema 
utilised  by  the  structure  editor  defines  the 
format  of  the  underlying  database  and 
thereby  enables  other  tools  to  use  the  data; 
users  are  able  to  invoke  a  related  support 
tool  to  obtain  HOOD-like  graphical  views 
of  the  Ada  programs. 

It  is  anticipated  that  users  of  the  TIPSE 
will  invoke  the  design  editor  to  specify  the 
high  level  design  of  software  systems;  at 
this  level  a  pictorial  view  is  often  more 
beneficial  in  illustrating  both  its  internal 
structure  and  the  relationship  with  other 
program  modules.  At  any  stage  the 
user  may  switch  to  a  textual  view  and 
continue  with  the  specification  using  the 
structure  editor.  Detailed  specification 
in  diagrammatic  form,  down  to  the  level 
of  individual  program  instructions  is  not 
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Figure  3:  The  structure  editor:  An  Ada  editor  for  part  of  an  Ada  program 
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thought  to  be  desirable  [13]  and  will  not 
be  supported.  The  current  facilities  within 
the  TIPi  E  have  not  yet  reached  a  level  of 
functionality  to  enable  evaluation  of  this 
approach. 

Support  for  software  reuse 

During  the  Eclipse  and  DRAGON  projects, 
much  work  was  undertaken  in  the  field  of 
software  reuse  [12,  14].  It  should  not  come 
as  a  surprise  therefore  that  the  TIPSE 
places  a  lot  of  emphasis  on  software  reuse. 
This  is  shown  both  in  terms  of  the  way  in 
which  the  environment  has  been  developed 
but  also  in  the  support  that  it  provides 
for  the  users.  Our  instantiations  of  the 
structure  editor  and  the  design  editor  have 
been  designed  to  support  software  reuse 
and  to  provide  the  user  with  access  to  a 
library  of  reusable  components  [15].  The 
available  components  are  compatible  with 
both  tools  and  can  be  viewed  in  a  textual 
or  graphical  mode. 

Our  experience  has  been  that  students 
working  through  the  TIPSE  have  found 
the  environment  complimentary  to  the 
emphasis  placed  on  reuse  within  the  soft¬ 
ware  engineering  courses  at  Aberystwyth. 
By  utilising  the  library  of  components, 
students  are  better  able  to  appreciate  the 
benefits  to  be  gained  from  both  designing 
with  reuse  and  designing  for  reuse. 

Design  method  support 

No  software  engineering  course  would  be 
complete  without  discussing  the  role  of 
design  methods.Whilst  it  is  possible  to 
teach  the  theoretical  aspects  of  a  design 
method  within  a  reasonable  period  of  time, 
the  learning  hurdles  for  the  support  tools 
often  negates  their  practical  usage.  The 
uniformity  of  user  interfaces  within  the 
TIPSE  makes  it  feasible  to  use  a  number 
of  design  tools  at  an  undergraduate  level. 


Specific  support  is  currently  provided  for 
the  HOOD  [16]  method  in  the  form  of 
the  IPSYS  HOOD  tool  set  [17].  Used 
widely  by  the  Aerospace  industry,  this  is 
a  well  respected  tool  kit  that  supports  an 
increasingly  popular  method.  Based  on 
the  underlying  TBK  facilities,  the  tools 
are  fully  integrated  with  many  aspects 
of  the  TIPSE  and  have  very  similar 
front  ends.  Using  this  environment,  the 
emphasis  of  the  teaching  can  be  placed  on 
the  example  method  rather  than  on  the 
complex  support  tools. 


Document  Preparation 


One  of  the  areas  to  benefit  most  from  an 
integrated  database  should  be  that  of  doc¬ 
umentation.  As  traditional  environments 
seldom  support  any  tool  interworking, 
system  documentation  is  often  out  of  step 
with  development.  With  the  facilities  of 
an  IPSE,  it  should  be  possible  to  solve 
this  problem.  To  ensure  compatibility, 
design  specifications  can  be  linked  into  the 
specification  of  component  interfaces,  for 
example,  and  textual  and  diagrammatic 
specifications  can  simply  be  different  views 
of  the  same  data.  Initial  investigations  into 
this  area  look  promising. 

The  environment  already  includes  a  struc¬ 
ture  editor  to  support  the  development 
of  high  quality  documents  using  the 
document  preparation  system  [18]. 
Furthermore,  the  adoption  of  SGML  [19] 
is  under  consideration.  Through  the  use 
of  templates,  this  facility  should  provide 
the  user  with  a  standard  structure  for 
the  particular  type  of  document  under 
production. 
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5  The  TIPSE  as  an  educa¬ 
tional  environment 

The  TIPSE  has  a  rich  set  of  high  level  tools 
that  are  available  for  its  users.  The  subject 
of  this  section  is  the  extent  to  which  the 
environment  can  be  used  to  facilitate  the 
educational  process. 

Initial  developments  on  the  TIPSE  con¬ 
centrated  on  producing  high  level  tools 
for  supporting  our  undergraduate  software 
engineering  courses.  These  tools  would 
all  have  graphical  front  ends  to  make 
them  more  attractive  to  their  users. 
Facilities  such  as  project  management 
tools,  configuration  control  tools  and 
graphically-based  design  tools  all  seemed 
to  be  desirable  facilities  in  an  educational 
environment. 

As  the  development  of  tin  high  level  tools 
proceeded,  it  became  clear  that  the  lower 
level  facilities,  the  actual  building  blocks 
of  the  environment,  were  'o  become  very 
important  to  the  teaching  perspectives  of 
the  TIPSE.  In  addition  to  forming  the 
foundations  of  many  of  the  higner  level 
tools,  the  database  and  user  interface 
facilities  have  much  to  offer  the  trainee 
software  enginee-,.  Within  the  TIPSE,  not 
only  are  studeits  able  to  gain  first  hand 
experience  of  using  integrated  tools,  they 
can  now  also  use  the  raw  facilities  for 
designing  and  implementing  their  own. 

Prototyping  is  now  considered  to  be 
a  very  important  aspect  of  software 
development.  The  advantages  that  the 
technique  provides  in  establishing  user 
requirements,  for  example,  is  widely 
accepted.  Our  experience  of  using  the 
TIPSE  for  advanced  software  engineering 
courses  has  been  that  the  user  interface 
facilities  are  very  well  suited  to  rapid 
prototyping.  After  an  initial  learning 
period,  we  have  found  that  students  can 
very  quickly  produce  a  fairly  sophisticated 


front  end.  Designing  user  interfaces  is 
notoriously  difficult  and  can  involve  a 
lot  of  tinkering;  fortunately  the  facilities 
provided  within  the  TIPSE  make  this  task 
a  lot  easier.  With  the  growing  realisation 
of  the  importance  of  designing  user  friendly 
interfaces,  this  area  is  likely  to  become  far 
more  significant 

The  database  is  equally  as  important 
as  a  stand  alone  facility.  Students  are 
instructed  on  the  Object  Management 
System  and  how  the  structure  of  data  to 
be  manipulated  is  defined  through  the  use 
of  a  data  definition  language,  detailing 
the  types  of  objects,  links  and  attributes 
which  can  occur  within  the  database.  They 
are  able  to  investigate  how  the  use  of  a 
echema  grants  visibility  to  the  object  types 
it  defines,  instances  of  which  can  then  be 
created,  manipulated  and  deleted.  Using 
a  high  level  language,  designed  to  simplify 
the  task,  students  are  able  to  experiment 
in  defining  schemas  and  in  populating  the 
database. 

Fig.  4  shows  a  simple  management  tool 
that  was  initially  developed  as  a  student 
project.  The  tool  provides  some  basic 
facilities  for  interrogating  and  updating 
the  database  and  has  been  enhanced 
with  the  addition  of  a  simple  front 
end  developed  using  FDL.  Other  student 
projects  have  lead  to  the  development  of 
more  sophisticated  front  ends  to  the  model 
using  the  generic  tools;  design  editors  and 
structure  editors  now  provide  a  complete 
suite  of  tools. 

One  of  the  main  educatiohal  benefits  of  the 
TIPSE  is  its  open  architecture.  New  tools 
can  be  added  to  the  environment  becoming 
fully  integrated  through!  the  sharing  of 
common  schemas.  To  support  this  facility, 
schemas  utilised  by  the  predefined  TIPSE 
tools  are  also  available  to  oqr  student  users 
thus  enabling  them  to  write  new  tools  to 
interact  with  the  database.  Modifications 
can  be  made  to  database  objects  and  the 
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Figure  4:  Project  management  tool 


effects  investigated  by  invoking  one  of  the 
predefined  tools.  This  kind  of  exercise  has 
largely  been  confined  to  our  more  advanced 
software  engineering  courses  but  the  results 
have  been  very  positive. 

5.1  Increraentality 

Central  to  the  learning  process  of  the 
TIPSE  has  been  the  idea  of  incrementality. 
Whilst  the  open  architecture  will  enable 
the  TIPSE  to  change  through  time  and 
thus  be  extensible,  it  will  also  develop  with 
its  users  and  will  change  in  accordance 
with  their  level  of  knowledge  and  skill. 
This  quality  can  be  achieved  in  many 
ways;  a  less  complex  tool  could  be 
replaced  with  a  more  advanced  tool,  for 
example,  the  exchange  of  a  textual  editor 
for  a  structured  editor.  Alternatively 
a  tool  could  be  enriched  by  adding 
to  its  functionality;  a  structure  editor 
that  supports  only  a  small  subset  of 


the  language  could  be  replaced  by  one 
supporting  a  larger  subset.  A  more  subtle 
example  might  be  the  introduction  of 
explicit  version  control  features. 

Given  our  commitment  to  the  principle 
of  minimal  surprise,  it  is  important  that 
an  incremental  change  to  a  tool  does 
not  invalidate  what  has  gone  before;  in 
particular,  the  same  way  of  manipulating 
the  user  interface  should  produce  the 
same  results  and  the  incremented  version 
should  continue  to  operate  successfully  on 
a  database  developed  under  the  previous 
version. 

In  the  class  room,  students  are  gradually 
introduced  to  the  structures  of  the 
language  through  a  logical  progression  of 
examples.  These  examples,  in  program¬ 
ming  terms,  explain  not  only  the  structure 
and  syntax  of  a  language,  but  also  its 
semantic  logic.  It  is  our  intention  to  retain 
this  paradigm,  primarily  through  the  use 
of  a  family  of  structure  editors,  a  decision 
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motivated  by  our  experience  on  other 
research  projects,  such  as  (12).  Through 
the  use  of  these  editors,  the  students  are 
presented  with  an  environment  in  which 
the  structures  they  have  studied  appear 
to  be  the  only  structures  in  the  language. 
The  user  is  freed  from  the  syntax  details 
of  the  new  structures,  whilst  at  the  same 
time  being  insulated  from  the  other  more 
complex  language  constructs  which  are  yet 
to  be  learned. 


within  a  given  group  may  use  levels  3  to 
5;  this  means  that,  when  students  invoke 
the  structure  editor,  they  will  be  offered 
this  choice  of  levels,  with  a  brief  indication 
of  what  each  provides.  As  the  course 
progresses,  the  lecturer  may  change  the 
range  to  allow  levels  5  to  8,  and  so  on. 

5.2  Applying  the  TIPSE  to  un¬ 
dergraduate  courses 


The  incremental  concepts  pose  an  ex¬ 
tra  burden  on  compatibility  within  the 
environment  where,  for  the  purposes  of 
teaching,  it  is  important  that  the  previous 
work  of  students  is  available  at  a  later  date 
so  that  they  may  learn  from  their  mistakes 
or  reuse  their  earlier  code.  Fortunately  the 
schema  facilities  of  the  database  and  the 
generic  tools  available  from  within  TBK 
have  made  this  task  much  easier. 

Incremental  editors  within  the 
TIPSE 

The  TIPSE  provides  a  family  of  structure 
editors,  all  of  which  are  instantiations  of 
the  generic  structure  editor,  driven  by  an 
abstract  syntax.  This  abstract  syntax 
represents  the  schema  for  the  underlying 
data  structure  and  is  the  same  for  all 
editors  in  the  family.  Incrementation 
is  achieved  by  changing  the  concrete 
syntax,  which  specifies  wnat  an  individual 
editor  may  create  and  how  it  views  the 
database;  multiple  view  both  textual 
and  diagrammatic,  are  specified  in  this 
way.  The  system  is  therefore  being 
implemented  such  that  although  the 
underlying  representation  is  constant,  the 
user  view  of  the  structure  can  change. 

To  control  the  incrementation,  the  TIPSE 
allows  students  to  choose  the  level  at  which 
they  will  work,  within  limits  set  by  the 
lecturer.  •  The  levels  are  numbered  and 
the  lecturer  can  specify  that  all  students 


The  TIPSE  has  been  designed  to  be 
applicable  to  software  engineers  with  very 
different  levels  of  experience.  Ultimately, 
it  is  our  intention  to  use  the  TIPSE  as  a 
practical  basis  for  a  number  of  external 
courses  run  for  industry.  Until  it  gains 
full  functionality,  the  the  environment  is 
currently  restricted  to  undergraduate  use. 

In  the  first  year  of  their  degree  course, 
Students  take  an  introductory  course  where 
they  learn  to  program  in  Ada  and 
become  familiar  with  basic  data  structures; 
emphasis  is  also  placed  on  introducing 
the  key  concepts  of  software  engineering. 
During  this  period,  through  a  process  of 
continual  assessment,  students  carry  out  a 
small  number  of  individual  projects.  The 
programming  complexity  is  usually  low, 
for  example,  a  menu  driven  temperature 
conversion  system,  or  a  simple  line  based 
editor.  However,  even  at  this  stage, 
students  are  expected  to  follow  a  well 
engineered  approach  to  the  development  of 
their  software. 

The  main  use  of  the  TIPSE  is  at 
the  level  of  the  integrated  front  end 
which  provides  access  to  tools  for  design, 
coding  and  execution  of  Ada  programs. 
The  incremental  nature  of  the  structure 
editor  closely  complements  the  teaching 
of  Ada,  and  should  be  well  suited  to  an 
introductory  course. 

Through  the  second  year,  the  student 
continues  to  study  and  write  Ada,  a 


107  11th  Annual  National  Conference  on  Ada  Technology  1993 


further  main  application  of  the  TIPSE 
is  the  support  that  it  gives  for  group 
project  work,  an  important  element  of 
the  software  engineering  course.  The 
actual  programming  tasks  are  not  too 
complicated;  the  role  of  this  exercice 
is  to  focus  the  students  attention  on 
the  group  and  the  interaction  of  group 
working.  The  project  groups  typically 
contain  six  students,  who  liaise  with  a 
client,  a  staff  member  who  also  acts  as 
a  consultant/advisor,  to  develop  a  project 
specification  and  follow  this  specification 
through  to  implementation,  delivery  and 
acceptance  testing.  The  facilities  that 
the  TIPSE  provides  for  project  man¬ 
agement,  configuration  management  and 
project  specification  nicely  complement  the 
material  presented  in  lectures.  Certainly, 
the  ease  with  which  the  tools  can  be  used, 
compered  to  the  command  line  interface  or 
hand  techniques,  encourages  the  students 
to  utilise  the  tools. 

Final  year  students  attend  a  course  on 
advanced  software  engineering,  where  they 
are 1  instructed  in  the  principles  of  IPSE 
technology,  the  development  of  meta  tools 
and  support  for  programming  in  the  large. 
As  'part  of  the  practical  element  of  this 
course  the  students  are  encouraged  to 
use  |  the  TIPSE  as  an  example  IPSE. 
Rather  like  the  medical  student’s  skeleton, 
the  student  can  learn  principles  from 
the  simple  structure  presented  by  the 
TIPSE,  by  exploring  the  make  up  of  an 
environment  with  which  they  are  already 
familiar.  Being  familiar  with  what  a  tool 
can  do,  the  students  can  concentrate  on 
how  the  tool  is  implemented.  A  typical 
project  may  involve  prototyping  a  user 
interface  or  manipulating  the  database; 
such  examples  were  described  earlier  in  this 
paper. 

The  scope  of  applying  the  TIPSE  to 
undergraduate  courses  is  not  limited  by  the 
currently  available  toolset,  its  extensible 


nature  make3  it  an  ideal  candidate 
for  the  final  year  projects  when  many 
students  produce  additional  tools  for  the 
environment.  The  knowledge  that  their 
tu  3l  will  actually  be  used  in  the  future 
by  other  students  provides  many  with 
the  incentive  to  produce  a  robust  tool 
when  they  might  otherwise  only  produce 
a  prototype.  The  use  of  TIPSE  based 
facilities  will  expand  courses  throughout 
the  degree  programme  as  appropriate  tools 
are  developed  to  support  them. 

5.3  Evaluating  the  TIPSE 

In  order  to  carry  out  a  reasonable 
evaluation  of  any  tool,  it  is  important 
to  establish  a  set  of  criteria  under  which 
the  evaluation  is  to  be  carried  cut.  In 
industry  such  an  evaluation  might  be 
carried  out  at  two  levels:  first  from  the 
point  of  user  satisfaction  and  second  from 
a  management  perspective.  Are  the  users 
happy  with  the  tool,  and  do  they  they  feel 
it  is  effective?  Are  the  managers  satisfied 
that  the  tool  has  provided  the  appropriate 
gains  to  justify  the  investment?  In 
education  a  similar  evaluation  might  be 
carried  out.  with  the  students  as  users 
and  the  lecturers  as  the  managers.  Student 
satisfaction  is  relatively  straight  forward  to 
measure.  If  they  use  a  tool  after  it  has 
been  introduced  and  then  continue  to  use 
it  when  any  associated  assignments  have 
been  completed,  then  one  might  reasonably 
assume  that  they  are  satisfied.  Certainly 
students  rarely  need  encouragement  in 
voicing  their  opinions. 

The  educational  benefit  gained  from  using 
a  tool  is  rather  harder  to  ascertain.  The 
difficulty  lies  in  establishing  a  control.  To 
request  that  a  particular  group  of  students 
use  manual  techniques  while  their  peers  are 
instructed  on  a  fully  integrated  graphical 
tool  seems  unreasonable.  Moreover  to 
be  effective,  such  an  approach  might  also 
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require  a  different  emphasis  in  associated 
lectures. 

In  conclusion,  the  evaluation  of  the  TIPSE 
has  largely  been  one  of  hear  cay.  The 
environment  is  still  in  its  infancy  and 
suitable  techniques  for  more  scientific 
evaluation  are  still  being  sought. 

6  Conclusion 

This  paper  has  attempted  to  give  a  flavour 
of  the  tools  provided  within  the  TIPSE, 
rather  than  to  detail  the  method  of 
implementation.  More  specific  information 
is  described  in  [1]. 

A  university  education  consists  of  a 
broadening  as  well  as  a  deepening  of 
knowledge;  at  Aberystwyth  emphasis  is 
placed  on  rigorous  software  engineering 
principles,  it  is  hoped  that  the  TIPSE 
will  support  and  enhance  the  perception 
of  these  principles.  It  could  appear 
that  the  TIPSE  provides  a  restrictive  and 
over  protected  environment  that  does  not 
equipe  students  for  the  situation  which 
they  may  subsequently  face  in  industry. 
We  feel  that  the  main  benefit  arises  when 
the  TIPSE  is  used  as  a  support  tool, 
to  reinforce  the  principles  of  the  lectures 
rather  than  to  give  emphasis  to  a  particular 
method  or  technique. 

Though  the  TIPSE  has  now  been  under 
development  for  a  number  of  years,  this 
has  largely  been  through  the  efforts  of 
postgraduate  students.  Only  in  recent 
months  has  full  time  effort  been  provided 
on  the  project.  As  a  consequence  of 
this  method  of  development,  the  project 
is  continuing  to  follow  a  phased  approach, 
with  the  software  being  released  in  several 
distinct  stages.  At  each  stage  the 
functionality  is  enhanced  and  the  reaction 
of  students  assessed.  The  current  release 
of  the  TIPSE  provides  many  powerful 
facilities  and  is  the  subject  of  evaluation 


by  both  undergraduate  and  postgraduate 
users. 
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The  Rapid  Development  Methodology  (RDM)  Is  an  alternative  means  of  developing  systems  to 
that  of  tha  conventional  waterfall  method.  RDM  has  been  developed  Independently  at  the  Jet 
P^fi-lsion  Laboratory  (JPL)  but  is  consistent  with  the  objectives  of  the  Evolutionary  Development 
preach  articulated  by  the  DoD.  Ada  with  its  modom  software  engineering  features  has  proven 
be  complimentary  to  RDM.  RDM  derives  from  rapid  prototyping  but  is  distinct  from  it.  Basic  to 
RDM  is  the  delivery  of  useful  operational  increments  of  the  system  to  a  using  organization  every 
nine  to  fifteen  months.  Each  incremental  delivery  builds  on  the  previous  ones  and  is  part  of  the 
final  delivered  system.  Documentation  and  other  integrated  logistics  support  items  of  a  formal 
system  development  are  evolved  so  in  the  end  the  delivered  system  wider  RDM  is 
indistinguishable  from  that  developed  under  the  conventional  method.  Significant  advantages  of 
RDM  include  the  satisfaction  of  true  user  needs,  delivered  system  functional  capabilities  during 
the  tenure  of  sponsors  and  users,  and  a  process  that  is  adaptive  to  jnging  funding  profiles  and 
user  requirements.  RDM  has  been  used  at  JPL  primarily  for  the  development  of  largo  software 
intensive  systems  w.th  over  30  incremental  deliveries  having  been  made.  Project  sizes  have 
ranged  from  $10  mil'ion  spanning  a  few  years  to  $100  million  over  a  period  of  10  years. 


Introduction 

This  paper  is  about  a  better,  faster, 
cheaper  approach  to  implementing 
software-intensive  systems,  that  has 
been  pioneered  and  refined  by  the  Jet 
Propulsion  Laboratory  (JPL).  This  new 
approach,  the  "Rapid  Development 
Methodology"  (RDM),  has  been 
successfully  employed  in  the 
development  of  Ada-based  systems, 
though  it  can  be  used  with  any  software 
language.  RDM  is  an  outgrowth  of  rapid 
prototyping  concepts  and  is  a  refinement 
of  the  evolutionary  acquisition  model.  1 

I 

RDM  employs  incremental  development 
and  fielding  of  the  system.  User  I 

experience  with  the  currently  fielded 
increment  of  the  system  provides  a  basis 
for  the  detailed  requiremer  ts  of  future 
deliveries.  This  assures  user 
satisfaction  at  the  end  of  the 
developmental  cycle.  Funding  changes 
and  uncertainties,  such  as  those  depicted 
in  Figure  1,  are  accommodated  by  fixing 
the  rrrent  delivery  (e.g. 
specifications,  budgets  and  schedules) 


and  making  necessary  adjustments  in 
future  incremental  deliveries. 

Similarly,  RDM  accommodates  evolving 
or  even  radical  changes  in  the  roles  and 
missions  of  system  users.  In  the  case  of 
one  Command  Center  System  the  mission 
has  evolved  from  a  focus  on  a  tactical 
engagement  with  the  Soviet  Union  to  one 
including  humanitarian  relief  and 
monitoring  national  unrest. 

Each  incremental  delivery  is  treated 
essentially  as  a  "complete  end-to-end 
requirements  definition, 
implementation  and  deployment  cycle." 
This  permits  evolution  of  the  system 
infrastructure  and  its  functionality, 
including  achieving  compliance  with  new 
and  evolving  standards  (e.g.  POSIX,  X- 
Windows,  MOTIF,  GOSIP,  computer 
security  standards)  as  commercial, 
standards-compliant  products  become 
available. 

New  technologies  can  likewise  be 
incorporated  into  the  system.  In  one 
case,  a  "main  frame"  database 
management  system  server  was  replaced 
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by  a  RISC-based  "workstation"  to 
achieve  better  system  performance  and 
transportability  at  less  cost  than  the 
annual  maintenance  costs  of  the  old 
system.  Another  example  is  the 
enhancement  of  the  Local  Area  Network 
(LAN)  with  an  FDDI-based  backbone  in 
the  fourth  incremental  delivery. 

ROM  and  Ada  have  proven  to  be  highly 
complementary.  The  objectives  of  the 
Ada  programming  language  are  to:  1 ) 
establish  a  common  programming 
language,  2)  embody  and  enforce  modem 
software  engineering  principles,  and  3) 
facilitate  the  transfer  of  software  to 
different  hardware  platforms  and 
operating  systems.  Linder  RDM,  Ada's 
embodiment  and  enforcement  of 
principles  such  as  abstraction, 
information  hiding,  program 
modularity,  localization,  uniformity, 
completeness  and  confirmability 
directly  supports  the  evolutionary 
growth  of  the  delivered  system. 
Independence  from  reliance  on  specific 
hardware  platforms  and  operating 
systems  facilitates  the  insertion  of  new 
technology  into  the  system.  In  fact,  RDM 
achieves  the  "desired"  benefits  of  Ada 
within  the  development  lifetime  of  a 
single  software  intensive  system. 

RDM  provides  a  mechanism  for  faster 
and  cheaper  development.  First,  the 
important  operational  needs  of  the  user 
are  met  through  a  prioritization  that 
determines  the  content  for  each 
incremental  deliver)'.  This  avoids  the 
cost  and  time  of  classical  methods  which 
require  the  development  of  "every 
conceivable  capability  that  can  be 
imagined"  to  avoid  discovering  omissions 
after  system  delivery. 

Successful  application  of  RDM  strongly 
suggests  adherence  to  the  80-20  rule. 
(The  80-20  rule  states  that  it  takes 
80%  of  the  total  effort  to  achieve  the 
last  20%  of  the  goal.)  Under  RDM  it  is 
possible  to  set  and  achieve  targets  for 
each  incremental  delivery  that  are 
something  less  than  the  ultimate  goal 
(i.e.,  80%).  After  just  a  few 


deliveries,  the  essential  portion  of  the 
goal  is  achieved  with  only  a  fraction  of 
the  effort  required  by  the  old,  "single 
thrust"  method.  Additionally,  some 
"project  management  items"  will  be 
eliminated,  since  each  incremental 
delivery  takes  approximately  one  year 
from  start  to  finish.  For  example,  there 
is  neither  schedule  time  nor  need  for  all 
the  formal  reviews  of  the  conventional 
development  method. 

Experience  with  RDM  has  lead  to  the 
practice  of  "just  in  time"  engineering. 
That  is,  do  only  essential  tasks  and  put 
off  non-essentials.  This  focuses  the 
efforts  of  the  staff  end  eliminates 
unneeded  work.  Documentation  is 
handled  on  a  "when"  and  "as  needed" 
basis,  with  review  comments 
incorporated  into  the  next  delivery. 

JPL's  experience  shows  that  a  single 
incremental  delivery  implements 
somewhere  between  a  third  and  half  the 
capability  resulting  from  a  normal  five 
year  conventional  development  cycle,  at 
the  same  level  of  effort.  Experience  has 
shown  that  RDM  allows  more  effort  to  be 
channeled  into  implementation  of 
capabilities. 


Description  of.  RDM 

First,  RDM  is  neither  rapid  prototyping 
nor  a  version  of  the  spiral  incremental 
development  model.  Rapid  prototyping 
is  used  to  validate  either  requirements 
or  design  approaches.  When  completed, 
the  prototype  is  generally  abandoned  and 
the  "real"  system  implemented.  Under 
the  spiral  model  a  system  is  developed  in 
increments  and  deployed  at  the  end  of  the 
development.  Each  increment 
progresses  through  requirements 
analysis,  design,  implementation,  test 
and  user  validation.  Hence,  the  common 
reference  made  to  it  is  "build  a  little, 
test  a  little." 

Contrary  to  rapid  prototyping,  RDM  is 
used  to  implement  systems.  The  intent 
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of  RDM  is  to  make  use  of  every  product. 
Experience  has  shown  there  is  some 
waste  attributable  to  several  factors. 

I'^e  of  the  system  results  in  changes  to 
the  users'  operational  procedures,  with 
subsequent  modifications  to  system 
requirements.  These  lead  to  design 
changes  and  "breakage"  of  the  delivered 
capabilities.  Besides  basic  system 
implementation,  RDM  incrementally 
develops  the  system  Integrated  Logistics 
Support(ILS)  into  a  full  capability  at 
the  conclusion  of  the  project.  The  ILS 
capability  provided  at  each  delivery  is 
tailored  to  meet  the  needs  of  that 
delivery  taking  into  account  that  the 
developers  provide  most  of  the  support, 
until  the  system  is  finally  turned  over 
to  the  government  for  operations  and 
maintenance. 

As  opposed  to  the  spiral  model,  RDM 
delivers  each  increment  of  the  system 
into  immediate  operational  use.  As  a 
result,  a  system  developed  under  RDM  is 
fully  operationally  tested  and  validated 
prior  to  turnover  to  the  government  for 
sustainment. 

RDM  is  a  specific  project  management 
approach.  It  has  a  set  of  underlying 
tenets.  It  prescribes  management 
policies  and  procedures  for  system 
implementation  issues  such  as  project 
planning,  systems  engineering, 
configuration  management  and 
documentation.  The  four  tenets  of  RDM 
are: 

1 .  Build  and  deliver  the  system  in  a 
series  of  regular  and  consecutive 
increments. 

2.  Actively  obtain  feedback  from 
actual  field  usage  and  incorporate  the 
feedback  into  the  system  requirements 
of  future  deliveries. 

3.  Involve  the  users  in  extensive 
interaction  throughout  the  development 
cycle. 


4.  Implement  the  system  with 
progressive  formality  so  as  to  achieve 
everything  essential  to  sustainment 
upon  delivery  of  the  final  increment. 

High  level  planning  is  done  during  an 
initial  project  definition  phase,  when  a 
consensus  between  the  developer  and 
customer  is  reached  on  a  target  final 
operational  capability  (FOC) 
requirements  specification,  a  system 
architecture,  an  overall  budget  and  an 
overall  schedule.  A  modular  and  flexible 
architecture  is  essential  to  support  the 
incremental  delivery  of  the  system  and 
the  evolutionary  specification  of  system 
requirements.  Modem  distributed 
information  system  architectures 
provide  one  class  of  examples  suitable  to 
RDM's  incremental  deliveries. 

An  overall  schedule  for  a  generic  roject 
is  depicted  in  Figure  2.  As  discur  >ed, 
the  project  under  RDM  consists  >f  a 
series  of  deliveries.  Each  deliver '  must 
go  through  a  "mini"  life  cycle  of  ts  own 
consisting  of  "mini"  phases  Thf  se  echo 
the  phases  of  a  conventional  de  .’elopment 
life  cycle  with  the  numbers 
corresponding  to  the  phases:  (1) 

Planning,  (2)  Requirements,  (3) 

Design,  (4)  Implementation,  (5) 
Integration  and  test,  (6)  Installation, 

(7)  Certification,  and  (8)  Operations 
and  sustainment. 

As  depicted  in  Figure  2,  the  overall 
planning  (phase  1 )  is  done  once  at  the 
beginning  of  the  project.  This  plan  is 
updated  and  modified  whenever 
necessary  (e.g.  overall  budget  changes). 
The  FOC  Requirements  Specification  is 
updated  as  the  system  evolves  and  users 
learn  more  what  their  real  needs  are. 

Each  delivery  begins  with  a  mini¬ 
planning  effort  which  determines  the 
specific  scope  of  the  delivery  (i.e. 
system  functional  requirements),  the 
budget  and  the  schedule.  Phases  two 
through  seven  are  repeated  once  for  each 
delivery.  And  of  course,  the  delivered 
system  is  operated  and  sustained 
continuously  after  the  first  delivery. 

Once  a  delivery  has  been  transferred  to 
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operations,  the  previous  delivery  has 
been  superseded  and  it  disappears.  It  is 
often  possible  for  the  Project  Definition 
to  overlap  the  first  one  or  two 
deliveries,  frequently  causing  them  to 
be  called  "preliminary  deliveries"  in 
recognition  of  the  lack  of  a  complete 
long-term  perspective.  These 
preliminary  deliveries  have 
characteristically  consisted  of 
capabilities  which  have  been  recognized 
as  essential  and  have  been  delivered 
previously  in  other  projects. 

Experience  has  shown  that  the  time 
interval  between  successive  deliveries 
(i.e.  transfers  of  capability  to  user 
operations)  should  fall  somewhere 
between  nine  and  fifteen  months.  A 
series  of  deliveries  with  intervals  less 
than  nine  months  have  proven  to  be 
impossible  to  sustain.  This  is  due,  in 
part,  to  the  effort  of  the  development 
staff  needed  to  sustain  (e.g.  fix 
problems)  the  previous  delivery.  Also, 
"too  little  implementation  time"  leads  to 
a  temptation  to  "cut  comers"  by 
compromising  other  phases  (e.g. 
integration  and  test).  Intervals  greater 
than  fifteen  months  begin  to  lose  the 
characteristics  of  RDM.  External 
influences  (e.g.  funding  changes, 
requirements  changes)  begin  to  upset 
the  desired  stability  of  the  current 
delivery.  A  delivery  cycle  that  fits  with 
the  government's  budgetary  cycle 
permits  securing  full  funding  of  the 
delivery  prior  to  the  commitment  to  the 
delivery.  Thus  the  delivery  can  be  made 
as  planned  without  budgetary  influence. 
Changes  in  future  funding  impacts  only 
future  deliveries. 

Individual  incremental  deliveries  need 
to  be  sufficiently  small  in  cost,  scope 
and  complexity  to  forego  the  safeguards, 
reviews  and  formality  associated  with 
the  conventional  development  methods. 
Otherwise,  the  five  to  eight  year 
conventional  development  cycle  cannot 
be  broken.  (18-24  months  are 
required  for  the  formal  reviews.  A 
similar  amount  of  time  is  required  for 
documentation.) 


Five  formal  reviews  have  been  identified 
under  RDM.  A  one  time  Project 
Definition  Review  at  the  end  of  the 
Project  Definition  Phase  assesses 
overall  project  plans  and  processes.  It 
gains  the  concurrence  of  all  parties  to 
the  project.  At  the  beginning  of  the 
delivery  cycle  the  sponsor's 
Configuration  Control  Board  holds  a 
Requirements  Review  to  baseline  the 
requirements  of  the  current  delivery. 

This  review  achieves  concurrence  among 
all  parties  as  to  the  established 
requirements  for  the  delivery.  A 
Delivery  Commitment  Review  is  held 
early  into  each  delivery  cycle  to 
demonstrate  understanding  of  the 
requirements  and  general  readiness  to 
complete  the  delivery.  This  review 
covers  system  requirements,  system 
design,  implementation  plans,  costs, 
schedules  and  risks.  Near  the  end  of 
each  delivery  cycle  a  Delivery  Pre-Ship 
Review  is  held  to  establish  readiness  to 
undertake  system  installation, 
integration  and  test  at  the  user's  site. 
Long  lead  time  installation  items  may  be 
shipped  and  begun  installation  prior  to 
the  Delivery  Pre-Ship  Review.  This 
review  covers  design  and 
implementation  status,  testing 
thoroughness  and  results,  plans  for 
testing  training,  operations, 
maintenance,  costs  and  schedules.  The 
delivery  culminates  with  a  Delivery 
Transfer  to  Operations  Review  which  is 
held  by  the  sponsor’s  Configuration 
Control  Board.  This  review  serves  as  a 
system  acceptance  review  for  the 
sponsor  and  user. 

The  RDM  approach  to  documentation 
emphasizes  supporting  usage  and 
sustainment  of  the  system.  Documents 
evolve  with  increasing  content  as  the 
system  evolves.  Documents  are 
delivered  as  they  become  available  or 
just  in  time  of  need.  They  reflect  the  "as 
built"  system.  Document  re-work 
within  a  delivery  cycle  is  minimized. 
Precise  document  suites  are  tailored  by 
the  specific  needs  of  the  project. 
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Project  planning  documents  may 
include:  Project  Ran,  Hardware 
Management  Ran,  Software  Management 
Ran,  Safety  Ran,  Product  Assurance 
Ran,  Integrated  Logistics  Ran,  Review 
Ran,  Documentation  Plan,  Configuration 
Management  Ran,  Integration  and 
Testing  Ran,  Security  Ran  and 
Shipping  Ran. 

Documents  delivered  within  each 
delivery  may  include:  Requirements 
Specification,  Integrated  Support  Plan, 
Segment  Requirements  Specification, 
Segment  Design  Document,  Interface 
Control  Document,  Database  Design 
Document,  Site  Concurrence 
Memorandum,  Integrated  Test  Rans  and 
Procedures,  Test/Analysis  Report, 
Security  Evaluation  Report,  Installation 
Drawings  Package,  Release  Description 
Document,  User  Manuals  and  Training 
Materials.  Figure  3  indicates  the 
progression  of  the  formality  of  the 
delivery  dependent  documents. 

Testing  under  RDM  emphasizes 
satisfying  the  user.  Its  key  outcome  is 
problem  identification.  Results  of 
testing  are  used  to  determine  what  is 
actually  included  in  the  delivery.  That 
is,  if  testing  has  shown  that  some 
segment  of  the  delivery  is  not 
operationally  viable  then  its  delivery  is 
postponed  until  a  later  date  or  until  the 
next  delivery.  Therefore,  all  deliveries 
are  made  on  time,  albeit  they  may  not 
provide  the  full  functionality  as 
originally  planned. 

A  major  testing  principle  is  that  to 
continue  to  test  a  system  within  a  single 
environment  using  a  fixed  set  of 
procedures  eventually  produces 
diminishing  returns  as  fewer  and  fewer 
problems  are  identified.  Exhaustive 
testing  is  recognized  as  impossible  to 
achieve.  Once  the  problem  time  curve 
begins  to  level  off  the  efficacy  of  testing 
is  increased  by  changing  the  focus  or  the 
environment.  This  is  depicted  in  Figure 
4. 


The  initial  focus  is  on  integration  testing 
employing  data  flow  threads  as  a  basis 
for  test  procedures.  Once  the  system  is 
working  as  a  unit  the  testing  emphasis 
may  be  shifted  to  requirements  testing 
to  assure  that  all  the  individual 
functional  capabilities  work  as  expected. 
Another  environment  is  generated  with 
tests  that  emphasize  operational  strings 
or  scenarios  that  emulate  the  anticipated 
use  of  the  system.  Changing  the  location 
of  the  testing  from  the  laboratory  to  the 
users'  site  where  each  set  of  previously 
used  test  procedures  are  repeated 
creates  further  test  environments. 
Security  testing,  acceptance  testing  and 
user  training  provide  additional 
environments. 

Finally,  the  use  of  the  system  for 
operations  by  real  users  provides  the 
final  test  environments.  For  this 
reason,  the  first  users  must  be 
considered  as  part  of  the  test  team.  No 
amount  of  formal  testing  is  going  to 
eliminate  the  first  users  uncovering 
problems.  Testing  needs  to  minimize  the 
number  of  problems  found  by  users. 
However,  real  use  is  essential  to 
uncover  performance  problems,  system 
weaknesses,  bottlenecks,  and  strain 
points.  On  this  basis  the  use  of  the 
system  for  another  application  or 
radically  different  operation  will 
constitute  a  new  environment  and  will 
undoubtedly  result  in  a  flux  of 
previously  unidentified  problems. 

Ada -Considerations 

Experience  with  Ada  based  projects 
using  RDM  has  shown  that  45%  of  the 
implementation  time  in  each 
incremental  delivery  is  spent  on 
preliminary  and  detailed  design 
activities.  Coding  and  unit  testing 
constitutes  25%  of  the  time  and 
integration  and  test  takes  the  remaining 
30%.  This  contrasts  with  the 
distribution  of  20%,  55%  and  25%, 
respectively,  that  typically  has  been 
experienced  with  the  conventional 
development  process. 
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The  greater  time  for  design  has  been 
attributed  to  the  additional  effort 
required  to  define  all  data  types  and 
develop  package  specifications.  Ada, 
being  a  strongly  typed  language, 
requires  more  time  to  define  and 
negotiate  all  required  data  structures 
and  type  definitions.  Less  time  is 
required  for  coding  under  Ada  and  RDM 
because  most  sub-program  interfaces 
are  negotiated  and  agreed  upon  during 
the  design  phase.  This  carries  over  to 
testing  where  very  little  test  time  is 
spent  dealing  with  data  type  errors  and 
sub-program  interface  mismatches. 

The  rigid  specification  of  software 
program  elements  (i.e.  procedure 
argument  lists,  data  types  and  external 
package  references)  minimizes 
problems  with  their  usage  by  the 
various  members  of  a  software 
development  staff. 

An  Ada  development  environment  has 
proven  most  beneficial  in  conjunction 
with  RDM.  The  Rational  Ada 
Development  System  provides  a  21 67 A 
document  generator,  configuration 
management  system,  language  sensitive 
editor  and  Ada  compiler.  The 
development  environment  assists  the 
developer  with  views  of  data  type 
definitions,  interdependency 
information,  syntactic  and  semantic 
assistance,  and  incremental  compilation 
support.  Code  is  first  generated  and 
compiled  on  the  Rational.  After 
achieving  a  successful  compile  the  code 
is  transferred  to  the  target  environment 
for  unit  testing.  This  transfer  is 
managed  automatically  by  the  Rational. 

RDM  necessitates  managing  several 
configuration  baselines.  The  current 
deployed  baseline  and  the  current 
development  baseline  are  necessary. 
Frequently,  an  update  to  the  deployed 
baseline  will  be  in  the  works,  as  well. 
Maintaining  previous  operational 
incremental  delivery  baselines 
constitutes  good  practice.  The  Rational 
provides  good  automated  support  to  the 


essential  configuration  management 
function. 

Several  features  of  the  Ada  language  have 
been  exploited  in  conjunction  with  RDM. 
Taking  advantage  of  the  inherent 
readability  of  Ada  code,  emphasis  has 
been  placed  on  developing  Ada  package 
specifications  containing  actual  Ada  code, 
rather  than  pseudo-code.  This  avoids 
the  step  of  translating  the  pseudo-code 
into  actual  Ada  code.  Also, 
interdependencies  of  the  compilation 
units  are  rigorously  defined.  Thus,  any 
undesirable  dependencies  or 
architectural  problems  can  be  identified 
and  corrected  in  the  design  phase  rather 
than  later  during  coding  or  integration. 

Ada  provides  extensive  error  checking 
during  compilation.  This  avoids  having 
to  find  many  errors  during  unit  testing 
on  the  target  system.  Finally,  extensive 
use  of  modularity  and  common  libraries 
permits  significant  code  re-use  from 
delivery  to  delivery.  This  provides  the 
ability  to  extensively  rework 
applications  with  a  minimum  of  code 
change. 


Summary 

Where  the  tenets  fit,  RDM  has  proven  to 
be  far  superior  to  the  conventional 
developmental  methodology.  RDM  is 
flexible  and  responsive  to  the  exigencies 
of  real  projects.  RDM  is  essentially  a 
design-to-cost  process  in  which  users, 
sponsors,  and  developers  must  reach 
consensus  on  priorities  and  scope  for 
each  incremental  delivery.  The  result 
should  be  the  best  capability  available 
for  the  available  funding  —  financially 
efficient  and  effective. 

RDM's  has  been  shown  to  be  highly 
responsive  to  programmatic  and 
technical  changes.  Even  the  obsolescence 
of  system  elements  during  the 
development  life  cycle  can  be 
accommodated  with  replacements  during 
the  succession  of  deliveries.  RDM  is 
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responsive  to  the  user  through  its 
involvement  of  the  user  throughout  the 
development  cycle.  The  overt  attention 
on  requirements  feedback  based  on 
operational  use  assures  user 
satisfaction. 

RDM  and  Ada  have  proven  to  be 
compatible  for  the  development  of 
software  intensive  systems.  Ada's 
modem  software  engineering  features 
facilitate  the  short  implementation 
period  of  the  incremental  deliveries 
essential  to  RDM.  Use  of  an  Ada 
development  environment  has 
contributed  to  the  successful 
employment  of  RDM. 

JPL  has  used  RDM  on  seven  software 
intensive  system  development  projects 
to  make  30  successful  incremental 
deliveries.  These  projects  include 
command  centers  for  the  USAF  Military 
Airlift  Command.  US  Transportation 
Command,  US  European  Command  and  US 
Army  Headquarters.  RDM  has  also  been 
used  to  develop  war  game  simulations 
for  the  US  Army. 

So  far,  JPL  has  been  the  sole 
practitioner  of  RDM.  It  remains  to  be 
seen  how  RDM  can  be  used  within  the 
government's  competitive  acquisition 
guidelines.  A  task  work  order  contract 
may  be  a  potential  viable  contractual 
candidate.  Still,  it  would  appear  that 
changes  in  Military  Standards  are 
necessary  to  recognize  development 
methods  such  a  RDM.  These  include  the 
areas  of  reviews,  documentation  and 
testing. 
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large  sets  of  requirements  to  the  design 


Afasicast 

Traditionally  there  has  been  a 
disconnect  between  software  requirements 
and  software  design  in  large  defense 
systems.  The  problem  begins  with  the 
major  product  of  the  requirements  phase, 
the  Software  Requirements  Specification 
(SRS).  Typically  this  document  is  intended 
for  management  and  the  customer  not  the 
design  engineer.  This  paper  describes  a 
process  to  bridge  the  gap  between  the 
requirements  phase  and  the  design  phase. 
This  process  is  called  a  requirements 
harvest.  The  requirements  harvest  is  a 
formal  process  for  handing  over 
requirements  form  the  requirments 
engineers  to  the  design  engineers. 

Introduction 

Traditionally  there  has  been  a 
disconnect  between  software  requirements 
and  software  design  for  large  defense 
system  using  DoD-STD-2167A.  There  are 
several  causes  for  this  problem.  The 
problem  begins  with  the  major  product  of 
the  requirements  phase,  the  Software 
Requirements  Specification  (SRS).  This 
document  is  intended  for  management  and 
the  customer  not  the  design  engineer.  As 
more  complex  systems  are  build,  it 
becomes  increasingly  difficult  to  hand  over 


engineer. 

Many  assumptions  are  made  as 
requirments  are  defined.  In  general,  these 
assumptions  are  poorly  documented. 
There  are  of  course  other  causes  for 
breakage  between  the  requirements  phase 
and  the  design  phase  of  a  large  software 
development  project.  This  problem  has 
been  recognized  by  the  Software 
Engineering  Institute  (SEI)  in  their 
Contractr:  Maturity  Model  (CMM)  [HUM87]. 

The  requirements  harvest  process 
was  defined  to  resolve  the  requirements 
hand-over  problem.  The  term 
'requirements  harvest’  is  used  because  the 
process  of  performing  requirements 
analysis  is  like  planting  a  crop  and  tending 
it.  While  you  may  have  grown  a  bountiful 
crop  (complete  requirements),  if  you  do  not 
effectively  harvest  the  crop  it  will  rot  in  the 
field.  Frequently  a  detailed  requirements 
crop  is  produced,  but  the  design  engineers 
foil  to  utilize  the  yield.  Instead,  they  hurry 
to  the  grocery  store  and  pickup  what  they 
can  find  leaving  the  requirements  to  ruin. 

The  requirements  harvest  concept 
will  work  with  most  requirements  analysis 
and  design  methods.  However,  the 
process  works  particularly  weil  with  an 
object  oriented  approach.  The  authors 
used  the  Coad-Yourdop  method  for  object 
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oriented  analysis  (OOA)  [COA91]  and  a 
modified  Buhr  and  Booch  method  for 
object  oriented  design  (OOD)  [B0091]. 
The  system  was  implemented  in  Ada  which 
does  not  support  full  object  oriented 
programming  (OOP).  This  paper  describes 
the  harvest  process  in  the  context  of  the 
aforementioned  methods. 

First,  this  paper  defines  the 
requirements  hand-over  problem  as  it 
relates  to  large  DoD  programs.  Next  the 
harvest  process  is  defined  in  detail, 
followed  by  the  authors  experience  in 
applying  the  process.  Finally,  the  benefits 
are  presented. 

EEQblsm 

Many  problems  face  today's 
software  development  teams.  Each  time  a 
software  development  team  solves  one  set 
of  problems,  another  set  is  created.  The 
following  paragraphs  summarize  problems 
encountered  as  the  software  engineering 
process  matures. 

Two  major  problems  have 
prevented  design  engineers  from 
designing  a  system  that  satisfies  the 
customers  expectations.  First, 
requirements  are  traditionally  incomplete 
and  incorrect.  Second,  when  the 
requirements  are  detailed  and  complex,  as 
they  are  with  large  systems,  the 
development  process  does  not  ensure  that 
the  design  engineers  completely 
understand  the  requirements.  The 
combination  of  these  two  problems  can  be 
devastating.  When  a  large  number  of 
errors  exists  in  a  large  software 
requirements  specification,  it  is  nearly 
impossible  to  utilize  it.  Because  of  these 
problems,  design  engineers  are  forced  to 
develop  their  own  requirements.  The 
result  is  a  design  that  does  not  satisfy 
anyone's  expectations,  except  possibly  the 
design  engineers. 

A  well  defined  software 
requirements  analysis  process  assists  the 
requirements  engineer  in  defining 


requirements  that  have  minimal  errors.  As 
a  result  the  detail  of  the  specifications  will 
increase.  Therefore,  in  solving  the  first 
problem  (excessive  requirements)  the 
second  problem  (passing  requirements  on 
to  the  design  engineers)  is  magnified. 

If  a  good  specification  is  developed 
for  a  large  complex  system,  some  errors 
will  still  exist  after  the  software 
requirements  review.  If  the  design 
engineers  do  not  have  a  thorough 
understanding  of  the  specification  they 
cannot  identify  requirements  errors  as  they 
progress  into  design.  As  a  result,  design 
errors  will  be  introduced  because  of 
misinterpreted  requirements. 

Once  the  software  development 
team  has  developed  complete 
requirements,  more  problems  are 
encountered.  In  a  waterfall  approach, 
software  requirements  are  developed  early 
in  the  program  and  never  updated.  After 
the  initiation  of  the  design  phase,  little  effort 
is  expended  to  keep  the  requirements  up 
to  date.  As  a  result,  the  requirements 
almost  never  represent  what  is  designed. 

To  summarize  the  problems, 
improving  requirements  specification 
increases  requirements  detail  and 
complexity.  These  detailed  and  complex 
requirements  are  difficult  to  pass  on  the 
design  engineers  such  that  they  can  satisfy 
them  and  identify  remaining  errors.  In 
addition,  these  requirements  are  not 
maintained  through  the  design  phase. 
Recognizing  that  there  is  no  silver  bullet  for 
software  engineering,  the  requirements 
harvest  process  resolves  several  of  these 
significant  problems. 

Ergggss 

The  requirements  harvest  process  is 
a  formal  three  step  process.  As  a  formal 
process  the  harvest  should  be  documented 
by  forms  (similar  to  walk-through  forms). 
These  forms  include  checklists  that  aid  the 
reviewers  in  reviewing  the  pertinent  data. 
The  steps  of  the  harvest  are  very  similar  to 
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structured  walk  troughs  done  in  the  coding 
phase.  Weber's  Key  Practices  of  the 
Capability  Maturity  Model  describes  many 
of  the  processes  that  need  to  be  performed 
in  software  development  [WEB91]  of  which 
the  requirements  harvest  is  just  one. 

Step  1 

The  software  specification  review 
(SSR)  initiates  hand-off  of  the  software 
requirements  from  requirements  engineers 
to  design  engineers.  At  the  SSR  the 
design  engineers  get  a  thorough  overview 
of  all  the  requirements  for  each  CSCI 
(Computer  Software  Configuration  Item). 
The  SSR  provides  a  general  overview  of 
the  requirements  and  is  not  intended  to 
discuss  each  requirement  in  detail.  For  a 
large  system,  a  general  requirements 
overview  (as  called-out  by  MIL-STD- 
1521 B)  requires  several  days  to  complete. 

At  the  completion  of  the  SSR  a 
requirements  harvest  is  initiated  to  ensure 
that  the  design  engineers  are  intimately 
knowledgeable  of  the  requirements  they 
are  designing  toward.  The  requirements 
harvest  is  initiated  by  the  lead  design 
engineer.  The  lead  design  engineer 
assigns  the  requirements  objects,  from  the 
object-oriented  requirements  model,  to 
each  of  the  design  engineers. 
Requirements  are  harvested  on  an  object- 
by-object  basis.  After  assigning  objects, 
the  lead  requirements  engineer  schedules 
a  series  of  requirements  reviews,  or 
harvests,  with  the  design  engineers.  Each 
harvest  is  supported  by: 

1)  the  lead  requirements  engineer, 

2)  the  requirements  engineer 
responsible  for  specification  of  the 
requirements  object, 

3)  the  lead  design  engineer, 

4)  the  design  engineer  responsible  for 
designing-to  the  requirements 
object. 

These  harvests  allow  the  requirements 
engineers  to  review  in  detail  the 


requirements  that  the  design  engineer  is 
responsible  for  satisfying. 

The  basic  premise  of  the  initial 
harvest  review  is  for  the  requirements 
engineer  to  explain  the' requirements  to  the 
design  engineer.  He  will  have  to  resolve 
any  anomalies  (ambiguities,  errors,  and 
inconsistencies)  that  exist.  Each  anomaly 
is  identified  through  the  initial  harvest. 
Additional  specification  may  be  required  to 
permanently  resolve  the  anonolies.  The 
requirements  engineer  leads  the  initial 
harvest.  In  the  harvest,  the  requirements 
object  is  discussed  in  detail  as  well  as  its 
relationships  to  other  requirements  objects. 
The  initial  harvest  includes  a  detailed  walk¬ 
through  of  the  following  specifications: 

•  attributes  [COA91] 

-  for  each  attribute:  description, 
purpose,  accuracy,  range, 
precision,  traceability 

-  class  unique,  object  unique, 
generalizations,  and 
specialization^ 

•  services  [COA91] 

-  for  each  service:  description, 
purpose,  inputs,  outputs,  timing, 
traceability 

-  class  unique,  object  unique, 
generalizations,  and 
specializations 

-  implied  services  (create,  delete, 
get,  set) 

•  relationships  to  other  objects 

-  for  each  instance  connection 
[COA91J:  attributes  required, 
purpose  for  the  requirement 

-  for  each  message  connection 
[COA91]:  services  supplied, 
services  requested 

-  for  each  part  and  whole 
relationship[COA91  ]:  relationships 
to  other  objects 

During  the  initial  harvest,  the 
requirements  engineer  is  responsible  for 
completing  software  change  requests 
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(SCRs)  for  all  requirements  errors 
identified  in  the  review.  The  initial  harvest 
ensures  all  requirements  have  been 
reviewed  in  detail  for  design 
considerations.  The  lead  requirements 
engineer  reviews  all  the  SCRs  generated 
and  corrects  all  approved  SCRs.  When  all 
the  SCRs  are  closed,  a  new  object 
oriented  requirements  model  is  released. 
After  the  new  model  is  released,  the  lead 
requirements  engineer  schedules  a 
second  series  of  reviews  to  discuss 
changes. 

Step  2 

Once  the  design  engineers  have 
completed  their  preliminary  design,  Ada 
Buhr  diagram  specifications  and  PDL 
package  specifications,  the  design 
engineer  walks  the  requirements  engineer 
through  the  design  specifications.  This 
second  harvest  identifies  additional  errors 
in  the  requirements  and  ensures  that  the 
requirements  are  satisfied  by  the  design. 
Again,  the  requirements  engineer  is 
responsible  for  completing  all  SCRs 
against  the  requirements.  Once  the  SCRs 
are  closed  the  requirements  engineer 
discusses  the  changes  with  the  design 
engineers.  The  preliminary  design  review 
(PDR)  is  held  following  the  closure  of  all 
SCRs  related  to  the  preliminary  design 
level  harvest. 

Step  3 

The  requirements  harvest  process  is 
completed  prior  to  the  critical  design 
review  (CDR).  When  a  design  engineer 
has  completed  his  Buhr  diagram  bodies 
and  Ada  PDL  bodies,  he  meets  with  the 
requirements  engineer.  The  design 
engineer  walks  the  requirements  engineer 
through  the  design  specification  to  identify 
any  requirements  errors  and  to  ensure  that 
the  requirements  are  satisfied.  Again,  the 
requirements  engineer  is  responsible  for 
completing  all  SCRs  and  coordinating  their 
resolution  with  the  design  engineer.  The 


CDR  is  held  following  the  closure  of  all 
SCRs  related  to  the  detail  design  level 
harvest. 

I 

EXOfiDSDCB 

The  authors  have  used  the 
requirements  harvest  on  a  large  distributed 
real-time  defense  system.  After  the  SRR, 
the  lead  design  engineer  created  a  design 
architecture  based  on  the  requirements 
model.  Individual  design  engineers  were 
then  assigned  to  each  requirements  object. 
The  harvest  process  was  initiated  following 
the  assignments.  The  harvest  was  the  first 
activity  of  the  preliminary  design  process. 

The  harvest  requires  a  form  to 
document  and  guide  the  processes.  The 
inclusion  of  this  form  is  the  result  of  the  first 
use  of  the  process.  When  the  harvest  was 
first  conducted  only  informal  notes  where 
keep  by  the  lead  requirements  engineer 
and  lead  design  engineer.  The  informal 
notes  did  not  provide  adequate  visibility 
into  the  process. 

This  project  marked  the  first  time  the 
software  development  team  performed 
object  oriented  requirements  analysis. 
While  all  of  the  development  team  received 
OOA  training,  only  the  requirements 
engineers  were  experts  in  the  method  and 
notation.  The  requirements  harvest 
enabled  the  requirements  engineers  to 
explain  the  OOA  notation  in  detail  with  the 
design  engineers.  Thus  the  harvest  eased 
the  paradigm  shift. 

Due  to  program  constraints,  the 
requirements  analysis  process  was  not 
allocated  adequate  resources. 
Additionally,  systems  engineering  did  not 
produce  a  complete  set  of  systems 
requirements  in  time  to  "seed"  the  software 
requirements  process.  As  a  result,  the 
software  requirements  were  incomplete. 
These  problems  were  identified  before  the 
requirements  harvest.  However,  the 
harvest  provided  metric  data,  SCRs,  to 
make  this  problem  more  evident  to 
management. 
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Management  supported  the  harvest 
process,  but  did  not  commit  adequate 
resources.  The  requirements  model 
contained  approximately  100  objects.  The 
design  team  consisted  of  7  engineers 
including  the  design  lead.  Management 
expected  the  harvest  to  be  completed  in 
two  to  three  days.  Initial  estimates  by  the 
software  engineers  indicated  that  it  would 
require  10  days.  The  harvest  actually  took 
3  weeks  to  complete,  with  the  average 
object  requiring  about  one  hour  of 
discussion. 

Over  100  SCRs  were  generated 
during  the  harvest.  This  number  was  much 
larger  than  expected.  The  large  number  of 
SCRs  was  attributed  to  several  factors. 

1.  Incomplete  system  requirements 

2.  Inadequate  resources  to  develop 
the  requirements 

3.  Limited  experience  with  OOA 

We  anticipate  that  a  program  with  better 
system  require  ments  and  more  resources 
spent  cn  analysis  would  not  generate  as 
many  SCRs.  On  this  particular  program, 
the  errors  were  found  before  the  design 
phase.  This  significantly  reduced  the  cost 
of  resolving  the  anomalies.  Without  the 
hkivest,  most  of  these  errors  would  not 
have  been  found  until  later  phases  of 
development,  thus  resulting  in  increased 
development  cost  and  schedule  overruns. 

Conclusion 

Many  DoD  systems  being 
developed  today  are  very  large  and 
complex.  For  development  methodologies 
to  be  successful  on  these  programs,  they 
must  produce  detailed  requirements 
specifications.  These  detailed 
requirements  specifications  must  be 
managed  carefully  to  ensure  that: 

1)  design  engineers  understand  the 
requirements  specification, 

2)  the  design  process  identifies 
requirements  errors, 

3)  the  requirements  and  design  remain 
consistent. 


The  requirements  harvest  process 
has  been  defined  to  manage  these 
requirements  issues.  The  requirements 
harvest  is  successful  because  it  formally 
ensures: 

1)  requirements  are  understood  by  the 
design  engineers  before  preliminary 
design  begins, 

2)  requirements  include  the  design 
engineers  perspective, 

3)  requirements  are  incrementally 
verified  through  the  design  process. 
For  the  farmer  of  the  future  to  be 

successful  he  must  improve  his  processes. 
He  must  utilize  new  technologies  to 
produce  larger  crops  with  less  resources 
and  with  increased  yields.  An  efficient 
requirements  harvest  is  essential  to 
realizing  increased  yields. 
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ABSTRACT 

attributed  to  the  fact  that  it  is  a  high  level  language 
designed  to  express  parallel  algorithms  and  their 
implementation  on  a  network  of  processing  components. 
In  addition,  the  Transputer  may  be  considered  an 
OCCAM  machine;  OCCAM  provides  the  efficiency 
equivalent  to  that  of  piogramming  a  conventional 
computer  at  the  assembly  language  level  fINMOS  88], 
However,  given  the  Congressional  Ada  Mandate  (Public 
Law  101-511  -  Sec.  8092,  and  Public  Law  102-172, 

See.  807?),  Ada  has  been  designated  the  systems 
development  language  of  choice  for  Department  of 
Defense  software  projects.  The  objective  of  this  project 
was  to  evaluate  the  Aisys_037  Ada  compiler  for  the 
Transputer,  currently  ihe  only  commercially  cvadable 
Ada  compiler  for  the  Transputer,  in  order  to  determine 
the  feasibility  of  implementing  the  required  software  in 
Ada. 

The  general  approach  that  was  taken  for  this 
project  was  to  run  a  series  of  software  benchmark  tests 
conforming  Xo  figure  1. 


80x84  -  DOS  5.0  TRANSPUTER 
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figure  1  -  Test  Plon 
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This  article  relates  the  exp.  tierces  of  a  project 
undertaken  at  the  Chemical  Resesrch,  Development  and 
Engineerin'  Center  of  the  U.S.  Army.  The  objective  of 
the  project  was  to  determine  the  feasibility  of  a  ’real  • 
time  Ada  implementation  on  a  transputer-based 
embedded  system.  Benchmarks  were  perfe.-med  in  Ada 
and  OCCAM  on  *he  8(7.86  and  T809  plj'fcnns  This 
report  contains  timing  comparisons  of  the  Whetstone 
and  PIWG  benchmarks  on  these  platfonus. 

INTRODUCTION 

The  Detection  Directorate  of  the  Chemical 
Research,  Development  and  Engineering  Center 
(CRDEC)  is  develop;ng  an  embedded  sy  stem  which 
utilizes  the  INMOS  T800  Transputer  Although  there 
ore  several  programming  languages  available  for 
systems  development  on  the  Transputer,  one  of  ihe  most 
widely  used  is  OCCAM.  OCCAM'S  popularity  can  be 


The  Whetstone  benchmark  program  [Cumow 
76]  was  developed  to  compare  processing  power  for 
scientific  applications.  The  program  goes  beyond 
measuring  pure  floating  point  performance  (’flops')  by 
including  features  found  in  typical1  scientific 
applications  such  as;  conditional  jumps,  array  indexing, 
integer  arithmetic,  procedure  calls,  and  evaluation  of 
elementary  functions.  The  PIWG  test  suite  [Pollack  90, 
Roy  90]  contains  a  series  of  experiments  that  assist  in 
the  evaluation  of  processor  performance,  clock 
resolution  and  compilation  efficiency.  Hartstonc 
[Weidcrman  89]  is  a  benchmarking  tool  for  evaluating 
hard  real-time  performance. 

The  initial  plan  was  to  test  these  software 
benchmark  sy  stems  across  the  Intel  80x86  and  INMOS 
T800  platforms  using  the  Alsys  Ada  compiler  for  32-bit 
DOS,  the  Alsys  Ada  compiler  for  the  Transputer,  and 
the  Meridian  Ada  compiler  for  32-bit  DOS.  The 
quantitative  results  from  these  tests  would  then  be  used 
as  the  basis  for  conclusions  and  recommendations. 

TECHNICAL  DISCUSSION 
HARDWARE/SOFTWARE 

The  hardware  system  which  was  used  to 
develop  and  test  the  benchmarks  consisted  of; 


Host  system  -  Gateway  2000:  8(K86DX/33MHz, 
EISA,  8MB  RAM 

Transputer  -  CSA  Transputer  board  for  PC; 

T800/20MHz,  4MB  RAM 

Cnee  the  DOS  executables  were  generated, 
timings  v/ere  measured  on  the  386/20MHz,  386/33MHz, 
and  486/33MIIz  systems.  The  386  systems  were 
equipped  with  80387  math  coprocessors. 

The  systems  software  used  to  support  the 
project  consisted  of: 

DOS  5.0 

Alsys  Ada  -  version  5.1  -  32  bit  DOS  compiler 
Alsys  Ada_037  -  version  5.4.2  -  Transputer  compiler 
Meridian  Ada  -  version  4.1.1  -  32  bit  DOS  compiler 
INMOS  Occam  Toolset  -  version  D7205 

Early  in  the  project,  the  Meridian  compiler  was 
abandoned  due  to  the  volume  of  compile  -time  and  run¬ 
time  errors  encountered  with  code  which  was 
successfully  tested  in  the  Alsys  environment.  Time  did 
not  permit  debugging  and  rewriting  a  large  volume  of 
code  Therefore,  the  revised  test  plan  matrix  conforms 
to  figure  2. 
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figure  2  -  Test  Plan  -  revised 


ACTIVITIES 

WHETSTONE  The  Whetstone  benchmark  has 
been  considered  somewhat  a  standard  benchmark  for  a 
number  of  years.  Unlike  the  Drystone  benchmark, 
Whetstone  is  intended  to  simulate  typical'  scientific 
applications  through  its  utilization  of  a  variety  of 
routines.  It  does,  however,  fall  short  in  several 


categories  of  contemporaiy  scientific  calculations.  In 
particular,  it  uses  small  arrays,  no  multi-dimensional 
arrays  are  employed,  it  is  dependent  on  the  speed  of 
floating  point  operations,  and  the  number  of  elementary 
function  evaluations  is  probably  atypical  of  current 
programming  models  [INMOS  91,  p259].  Despite  these 
observations,  it  still  provides  a  legitimate  baseline  for 
the  evaluation  required  in  this  project.  Whetstone  was 
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successfully  coded  and  tested  in  both  Ada  and  Occam, 
and  run  on  the  80x86  and  T8C0  platforms. 


PROCEDURES 


PIWO  The  Performance  Issues  Working 
Group  of  the  ACM  has  made  available  a  series  of  Ada 
benchmarks  which  can  be  used  in  the  evaluation  of  Ada 
compilers  across  a  range  of  hardware  platforms.  The 
test  suite  assists  in  the  evaluation  of  execution  time  and 
compilation  time.  It  wa3  determined  for  this  project 
that  the  compilation  time  tests  were  of  little  value  at 
this  stage  in  the  project;  therefore,  emphasis  was  placed 
on  the  evaluation  of  execution  timings.  In  particular, 
there  are  four  test  areas  that  made  up  the  critical  area  of 
performance  testing.  They  are: 

1.  Clock  Resolution  (A000090)  This  test 
illustrates  CFU  clock  resolution  available  to 
Ada. 

2.  DELAY  Resolution  (YOOOOOl)  Measures  the 
resolution  of  the  DELAY  feature  of  Ada. 

3.  Procedure  Call  Overhead  (P000005/6/7) 
Measures  procedure  call  overhead  time  in  Ada. 

4.  Hennesy  Tests  (A000094A-K)Scries  of  tests 
which  measure  performance  in  a  variety  of 
areas  including:  recursion,  integer  and  real 
matrix  multiplication,  and  sorting  (data 
movement). 

These  tests  were  successfully  performed  in  Ada 
on  both  the  80x86  and  T800  platforms. 

HARTSTONE  The  Hartstone  benchmark  is  a 
set  of  timing  requirements  for  testing  a  system's  ability 
to  handle  hard  real-time  applications  [Weiderman  89]. 
The  complete  Hartstone  benchmark  consists  of  five 
categories  of  tests:  PH  Series,  PN  Series,  AH  Series,  SH 
Series,  and  SA  Series  [Weiderman  89,  p5].  The  only 
test  successfully  implemented  in  Ada  to  date  is  the  PH 
Series.  This  test  provides  feedback  for  a  set  of  tasks 
which  are  periodic  and  harmonic. 

The  PH  Series  was  successfully  tested  on  the 
T800  platform  in  Ada;  however,  the  80x36  DOS  tests 
failed  to  provide  reliable  results.  Best  estimation  is  that 
as  the  period  in  milliseconds  began  to  approach  the 
clock  resolution  available  through  the  Ada/DGS 
environment,  the  system  would  "hang";  apparently 
attributable  to  DOS.  Therefore,  the  quality  of 
comparable  80x86/T800  results  was  compromised. 
Because  of  deadline  constraints,  it  was  determined  that 
the  Hartstone  benchmarks  could  not  be  successfully 
implemented  and  therefore  omitted  from  this  report. 


All  benchmark  development,  testing  and 
implementation  was  performed  on  the  hardware  and 
software  previously  noted.  Once  the  executables  were 
generated,  testing  was  conducted  according  to  figure  2  . 
All  compilations  and  bind:ng/linking  optimization 
options  are  contained  in  APPENDIX  A. 

RESULTS 

Test  results  are  contained  in  figures  3  -  5.  A 
key  point  worth  noting  is  that  the  Ada/Transputer 
environment  is,  in  effect,  a  runtime  environment.  That 
is,  the  execution  of  the  Ada  generated  code  is 
supervised  by  the  ISERVER.  This  runtime  environment 
does  not  permit  the  Ada  code  access  to  the  high  priority 
one  microsecond  clock  resolution  available  on  the  T800. 
The  OCCAM  environment,  however,  does  permit 
OCCAM  code  one  microsecond  access.  Therefore; 
perhaps  one  of  the  most  interesting  charts  is  the 
WHETSTONE  comparison.  The  other  charts,  however, 
do  provide  valuable  information  on  the  comparison  of 
Ada  executables  on  20MHz  and  33MHz  processors 
utilizing  different  architectures. 


CONCLUSIONS 

The  CBMS  under  development  by  CRDEC 
requires  one  microprocessor  feature  that  is  not 
supported  by  the  80x86  line  of  processors;  tLat  is,  the 
requirement  to  have  <  3  microsecond  resolution.  The 
dilemma  highlighted  by  this  study  concludes  that  the 
current  Ada  environments  available  fall  short  of 
providing  this  feature  on  the  T800,  even  though  it  can 
be  supported  via  OCCAM. 

A  variety  of  options  exist  in  the  pursuit  of  a 
solution  to  this  problem.  Perhaps  the  most  interesting 
would  be  that  of  developing  the  CBMS  software 
support  system  using  both  Ada  and  OCCAM.  This 
option  may  satisfy  both  the  timing  constraints  of  the 
CBMS  project  as  well  as  the  Congressional  Ada 
Mandate.  One  item  missing  in  permitting  this 
recommendation  is  evidence  of  the  real-time  timing 
requirements  of  OCCAM.  Comparative  data,  such  as 
that  provided  in  this  report,  illustrating  OCCAM’S 
statistics  in  similar  PIWG  and  Hartstone 
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implementations  would  be  helpful.  Such  data  could 
provide  valuable  insight  as  to  whether  or  not  OCCAM 
may  be  a  viable  alternative  or  supplement  to  the  Ada 
development  environment. 


[INMOS  91]  INMOS  Limited 
OCCAM  2  Toolset 
SGS-Thomson  Microelectronics  Inc., 
Colorado  Springs,  1991 
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figure  3  -  Clock  Resolution/Whetstone  Results 
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figure  4  -  Hennesy  Test  Results  (P1WG  Test  Suite) 
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figure  5  -  Delay  Resolution/Procedure  Call  Overhead 


11th  Annual  National  Conference  on  Ada  Technology  1993 


APPENDIX  A 

OPTIMIZATION 

All  code  was  compiled  and  linked  taking  advantage  of  optimization  features  provided  by  each  specific 
development  environment. 


Adi-P-fiS 

Compiler  -  Alsys  Ada  for  32-bit  DOS  -  version  5.1 

Compile  options  -  IMPROVE*^  CALLS  =  INLINED 

REDUCTION  »  EXTENSIVE 
EXPRESSIONS  -  EXTENSIVE  ) 


CALLS  -  INLINED: 

REDUCTION  -  EXTENSIVE: 

EXPRESSIONS  -  EXTENSIVE: 

Bind  options  -  TIMER  =  FAST 
TIMER  *  FAST: 


Call  will  be  inlined  for  subprograms  that  aren't  directly  or  indirectly 
recursive  in  response  to  INLINE  pragma. 

Performs  analysis  of  intermediate  program  representation  to  eliminate 
numerous  run-time  checks  and  removal  of  dead  code. 

Performs  common  subexpression  elimination  and  additional  register 
optimization. 

High  resolution  timer  used  for  the  implementation  of  the  DELAY 
statement. 


Compiler  - 
Compile  options  • 


Alsys  Ada  for  the  Transputer  -  version  5.4.2 
IMPROVE ”=(  INLINE  «  PRAGMA 

REDUCTION  -  EXTENSIVE 
EXPRESSIONS  -  EXTENSIVE  ) 


INLINE  *  PRAGMA:  Same  as  CALLS  ■  INLINED  above. 

REDUCTION  -  EXTENSIVE:  Same  as  REDUCTION  -  EXTENSIVE  above. 

EXPRESSIONS  -  EXTENSIVE:  Same  as  EXPRESSIONS  -  EXTENSIVE  above. 

Bind  options  -  FAST_MAIN  -  YES,  FAST.TASK  =  YES 

FAST_MAIN  *  YES:  Attempt  to  allocate  the  primary  stack  of  the  main  program  iu  a  low- 

addressed  area  which  could  be  mapped  to  the  internal  on-chip 
memory  of  the  Transputer. 

FAST_TASK  *  YES:  Attempt  to  allocate  the  primary  stack  of  the  task  in  a  low-addressed 

ares  which  could  be  mapped  to  the  internal  on-cfcip  memory  of  the 
Transputer. 


OCCAM 

Compiler  - 
Compiler  options  - 

/a: 

A8: 

/h: 

Linker  options  -  A8  !h 
A8: 

/h: 

Code  Collector  options: 
A: 

Host  file  server:  /se 
/se: 


INMOS  OCCAM  Toolset  -  version  D7205 
/a  A8/h 

Prevents  compiler  from  performing  alias  checking,  and 
prevents  usage  checking. 

Compile  for  T800  processor. 

Produces  code  in  HALT  mode. 


A 


Specifies  T800  ns  target  processor. 

Generates  a  linked  unit  in  HALT  mode. 

Creates  a  bootable  file  for  a  single  transputer. 

Terminates  the  server  if  the  Transputer  error  flag  is  set. 
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Defense  Software  Repository  System  Panel 

Moderator:  Joanne  Piper,  DISA/CIM 

Panelists:  Marrea  Riggs,  Army 

Patti  Hicks,  Defense  Logistics  Agency 

Rob  Rutherford,  Air  Force,  Standard  Systems  Center 

Jim  Wheeler,  Navy 
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Ada  in  Undergraduate  Computing  Education: 
Experience  &  Lessons  Learned 

Moderator:  John  Beldier,  University  of  Scranton 

Panelists:  Mike  Feidman,  George  Washington  University 
Nick  DeLIilo,  Manhattan  College 
Jim  Smith,  Leymoye  College 
John  W.  McCormick,  State  University  of  New  York 
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Programming  in  the  Large 
Moderator:  Dr.  Donald  Mullikin,  FAA 
Panelists: 
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Reuse  Interoperability  Group  (RIG) 

Moderators:  Jim  Moore,  IBM 

Dave  Dikel,  Applied  Expertise,  Inc. 

Panelists:  Eric  Beser,  Westinghouse 
Linda  Braun,  MountainNet 
Pam  Arya,  General  Research  Corp. 

David  Dikel,  Applied  Expertise 
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TRANSITION  TO  ADA:  A  CASE  STUDY 

Urban  LeJeane  and  Murray  Kirch 
Stockton  State  College 
Pomona,  New  Jersey  08240 


SUMMARY 

This  paper  describes,  in  case  study  format, 
the  pedagogical  change  to  Ada  from  Pascal  at 
Stockton  State  College.  The  transition  was 
started  in  the  Fall  1988  semester.  During  that 
semester  Ada  was  introduced  into  the  Operating 
Systems  and  Programming  Language  Structures 
courses.  The  metamorphosis  was  complete  in 
die  Fall  1991  semester  with  the  adoption  of  Ada 
in  our  Programming  and  Problem  Solving  I 
course,  which  is  based  on  the  ACM  CS1  guide¬ 
lines. 

The  experience  has  proven  to  be  pedagogi- 
cally  sound  and  enthusiastically  supported  by 
both  faculty  and  students.  A  key  to  the  success¬ 
ful  transition  was  the  initial  introduction  of  Ada 
at  die  senior  level  and  subsequently  incorporat¬ 
ing  the  use  of  the  language  progressively  lower 
in  the  curriculum.  The  philosophy  was  based 
upon  the  premise  that  you  do  not  have  to  teach 
upper  level  students  how  to  program  and,  addi¬ 
tionally,  upper  level  students,  after  being  ex¬ 
posed  to  Ada,  would  become  formal  and  infor¬ 
mal  tutors  and  laboratory  assistants. 


GENERAL  BACKGROUND 

Stockton  State  College  is  a  moderately  sized 
liberal  arts  college  located  in  Pomona,  New  Jer¬ 
sey  which  is  about  twenty  minutes  to  the  Atlan¬ 


tic  City  boardwalk.  The  school  has  slightly  over 
5,000  full  time  equivalent  students  and  offers 
degrees  in  a  variety  of  liberal  arts  and 
professional  majors.  The  Computer  and  Infor¬ 
mation  Sciences  (INFO)  program  is  domiciled 
in  the  Professional  Studies  Division.  Profes¬ 
sional  Studies  also  includes  Business  Studies 
and  a  variety  of  health  related  programs.  The 
INFO  program  supports  approximately  125 
majors  and  has  eight  full-time  and  one  half-time 
faculty  members. 


The  INFO  program  offers  both  BA  and  BS 
degrees.  The  curriculum  is  based  upon  a  com¬ 
mon  coir  of  courses  which  is  required  for  all 
majors.  BS  candidates  chose  between  four  ma¬ 
jor  tracks  while  BA  candidates  tailor  their  pro¬ 
grams  to  satisfy  their  individual  career  goals 
including  a  broader  liberal  arts  component 


The  common  core  of  courses  required  of  all 
INFO  majors  are: 


INF0 1206 
INFO  2101 

INFO  2102 

INFO  2210 

INFO  2222 

MATH  2225 
MATH  2215 


Statistics  I 
Programming  and 
Problem  Solving  I 
Programming  and 
Problem  Solving  II 
Systems  Analysis  and 
Design 

Fundamentals  of 
Information  Systems 
Discrete  Mathematics  I 
Calculus  I 
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The  four  concentration  tracks  for  BS  candi¬ 
dates  are  Computer  Science,  Information  Sys¬ 
tems,  Management  Information  Systems,  and 
Computer  Education.  All  four  tracks  require  51 
credits  of  applicable  concentration  and  cognate 
coursework  in  addition  to  the  common  core. 
BA  candidates  are  required  to  complete  35 
credits  of  coursework  in  computer  and  cognate 
courses  above  the  common  core  requirement. 


ADA  BACKGROUND 

In  the  early  eighties  Stockton  embraced  the 
educational  concept  of  emphasizing  a  single 
programming  language  for  instructional  pur¬ 
poses  as  opposed  to  a  sampling  of  languages 
that  was  prevalent  at  the  time.  The  language  of 
choice  was  Pascal.  The  only  time  other  lan¬ 
guages  were  taught,  and  continue  to  be  taught, 
is  when  they  have  application  features  not  in¬ 
cluded  in  the  primary  language.  File  processing 
using  COBOL,  numerical  methods  using  FOR¬ 
TRAN,  and  artificial  intelligence  using  LISP 
and  Prolog  are  examples. 

As  the  decade  progressed,  the  Stockton  com¬ 
puter  science  curriculum  placed  increasingly 
greater  emphasis  on  emerging  software  engi¬ 
neering  concepts.  It  became  painfully  clear  that 
standard  Pascal  lacked  features  that  would  pro¬ 
vide  strong  support  for  major  software  engineer¬ 
ing  principles.  Consequently,  faculty  decided  to 
examine  other  languages  to  determine  one  most 
appropriate  for  the  INFO  program. 

One  of  the  primary  goals  in  the  instructional 
language  selection  process  was  the  capacity  of  a 
language  to  be  broadly  included  in  the  curricu¬ 
lum.  Wherever  possible,  within  the  limits  of  a 
liberal  arts  college  curricular  requirements,  the 
Stockton  program  incorporates  the  ACM  cur¬ 
riculum  guidelines. 


After  an  extensive  evaluation  of  many  lan¬ 
guages,  Ada  was  selected  as  the  language  of 
instruction.  The  support  for  software  engineer¬ 
ing  principles  plus  an  exceptionally  high  level 
of  standardization  made  Ada  the  clear  choice. 
Additional  factors  were  the  emergence  of  vali¬ 
dated  Ada  compilers  for  IBM  PC  compatible 
platforms  and  Stockton's  close  proximity  to  the 
Federal  Aviation  Agency  Technical  Center  in 
Pomona,  New  Jersey.  Stockton  has  historically 
placed  many  cooperative  education  students  at 
the  Tech  Center. 


ADA  EVOLUTION 

Murray  Kirch,  the  senior  faculty  member  in 
the  department,  was  instrumental  in  the  selec¬ 
tion  process  and  the  subsequent  faculty  training. 
It  is  axiomatic  that  there  must  be  a  strong  and 
dedicated  leader  if  a  project  of  this  size  is  to  be 
carried  to  fruition. 

Before  implementing  Ada  in  any  course, 
substantial  groundwork  and  preparation  is  re¬ 
quired.  If  the  program  is  to  succeed,  there  must 
be  strong  faculty  preparation.  The  Stockton 
transitional  process  commenced  with  Murray 
Kirch  attending  an  intensive  4-week  faculty 
seminar  at  Tuskegee  University.  Later  Murray 
conducted  a  one  week  Ada  workshop  for  faculty 
members  on  the  Stockton  campus.  Non-com¬ 
puter  science  faculty  members  were  especially 
encouraged  to  attend  the  workshop  that  was 
supported  by  the  institution. 

It  was  decided  to  start  the  Ada  transition 
process  by  initially  employing  the  language  in 
upper  level  courses.  This  would  enable  faculty 
to  gain  experience  in  using  Ada  with  well-pre¬ 
pared  students  before  attempting  to  introduce  it 
in  large,  introductory  level  courses.  This  also 
produced  a  cadre  of  student  assistants  for  lower 
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level  courses  to  be  t?ught  in  subsequent  semes¬ 
ters. 

The  transitional  goal  was  established  to  take 
place  in  a  three  year  period.  The  goal  for  die 
first  year  was  to  introduce  Ada  into  Juo- 
ior/Senior  level  courses.  The  second  year  ob¬ 
jective  was  to  incorporate  Ada  in  Sophomore 
lever  courses.  The  third  year  was  the  year  that 
completed  the  process  with  the  introduction  of 
Ada  into  Freshman  level  courses  which  induced 
the  CS1  and  CS2  courses. 

During  the  fall  semester  of  1988  Ada  wan 
introduced  to  the  Stockton  curriculum  with  the 
offering  of  Operating  Systems  and  Program¬ 
ming  Language  Structures  Ada's  tasking  ability 
made  it  an  ideal  programming  language  choice 
in  the  operating  systems  course.  In  the  .pro¬ 
gramming  language  course,  Ada  was  both  an 
object  of  study  as  well  as  the  implementation 
language  for  a  language  translation  project. 

The  spring  semester  of  1989  witnessed  the 
incorporation  of  Ada  as  the  language  of  choice 
for  a  software  engineering  course.  Stockton  also 
co-hosted  the  S<;venth  Annual  National  Confer¬ 
ence  on  Ada  Technology  in  Atlantic  City  during 
the  semester.  During  the  fall  1989  semester 
Ada  was  introduced  into  the  sophomore  level 
course  in  data  structures. 

During  the  fall  of  1990  and  the  spring  of 
1991  Ada  was  the  language  used  in  the  fresh¬ 
man  level  courses,  Programming  and  Problem 
Solving  II  (CS2)  and  Programming  and  Problem 
Solving  I  (CS1).  This  completed  the  transition 
from  Pascal  to  Ada. 


are  embedded  in  our  Programming  and  Problem 
Solving  II  (CS2)  course  The  Data  Structures 
course  enables  students  to  gain  experience  with 
a  more  sophisticated  use  of  generics  and  other 
Ada  features.  The  Operating  Systems  course  is 
a  natural  for  the  introduction  of  concurrency 
and  tasking  using  problems  such  as  the  dining 
philosophers  and  the  readers  and  writers. 

Upper  level  courses  featuring  Ada  features 
include  Programming  Language  Structures 
(PLS)  and  Software  Engineering.  In  the  PLS 
course  Ada  is  treated  as  an  object  of  study  and 
additionally  is  used  as  an  implementation  lan¬ 
guage  to  write  a  sophisticated  project  such  as  an 
interpreter  for  a  Pascal  type  language.  The 
Software  Engineering  may  be  conceptualized  as 
a  capstone  course  using  large  team  projects  en¬ 
compassing  both  maintenance  and  startup  pro¬ 
jects.  Because  of  the  proximity  of  the  Federal 
Aviation  Agency  Technical  Center,  and  the  fact 
that  many  students  by  this  time  have  spend  a 
semester  co-op  at  the  Tech  Center,  an  air  traffic 
control  project  is  typically  implemented.  A 
maintenance  project  available  from  the  Soft¬ 
ware  Engineering  Institute  is  frequently  imple¬ 
mented  as  the  maintenance  component. 

When  Ada  was  first  introduced  the  only 
compiler  available  to  students  was  VAX  Ada 
running  on  a  DEC  VAX  cluster  consisting  of  a 
VAX  6410  and  a  VAX  6310.  In  1989  two  Me¬ 
ridian  compilers  were  made  available  to  Stock- 
ton  faculty  through  the  Annual  Conference  on 
Ada  Technology's  Academic  Outreach  program. 
By  1990  a  Novell  network  was  outfitted  with  a 
Meridian  Ada  compiler,  providing  students  and 
faculty  with  the  option  of  using  the  PC/MS- 
DOS  or  VAX/VMS  based  product. 


The  major  Ada  concepts  introduced  in  the 

course  sequence  included  the  introduction  of  Meridian  also  made  PC  based  compilers 

exception  handling,  packages,  and  attributes  in  available  to  students  at  substantially  reduced 
the  Programming  and  Problem  Solving  I  (CS1)  prices.  Many  Stockton  students  purchase  Ada 

course.  Generics,  advanced  exception  handling,  compilers  to  be  used  on  their  own  computer 

abstract  data  types  and  team  oriented  projects  systems. 
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OBSERVATIONS 

Several  lessons  were  learned  during  the 
process.  Faculty  development  is  an  ongoing 
process  with  members  attending  frequent  con¬ 
ferences  and  training  seminars.  Additionally, 
Stockton  faculty  have  presented  seminars  and 
papers  concerning  technical  and  educational  as¬ 
pects  of  software  engineering  with  Ada  at  re¬ 
gional,  national,  and  international  conferences. 

Textbook  selection  presented  an  initial 
problem.  The  selection  was,  and  is,  limited 
when  compared  to  the  plethora  of  available  Pas¬ 
cal  books.  The  scarcity  is  especially  noticeable 
at  the  introductory  and  intermediate  levels. 
However,  the  quantity  and  quality  of  available 
Ada  textbooks  are  dramatically  increasing.  A 
list  of  available  textbooks  appears  in  Feldman1. 

As  a  first  programming  language  Ada  does 
present  some  practical  problems.  Developmen¬ 
tal  environments  are  not  as  user-friendly  as 
those  available  with  Pascal.  This  deficiency  is 
especially  noticeable  when  compared  with  the 
exceptionally  friendly  front-end  provided  with 
Turbo  Pascal.  The  increased  time  required  to 
produce  an  executable  program  using  Ada  can 
be  a  source  of  student  frustration. 

Initial  student  programming  frustration  may 
be  substantially  overcome  by  the  judicious  use 
of  supplied  source  code.  A  supplied  package 
can  hide  many  required  implementation  details 
from  students  until  they  are  ready  to  compre¬ 
hend  the  Ada  language  complexity. 

CONCLUSIONS 

The  transition  to  Ada  at  Stockton  has  pro¬ 
duced  far  more  advantages  than  difficulties. 
Students  are  exposed  to  software  engineering 


concepts  starting  with  their  first  course.  The 
use  of  Ada  has  facilitated  more  substantial  stu¬ 
dent  projects  throughout  the  curriculum  begin¬ 
ning  with  the  introductory  level  course.  A  ma¬ 
jor  side  effect  has  been  expanded  student  em¬ 
ployment  opportunities. 

Student  reaction  to  Ada  has,  in  general,  been 
enthusiastic.  There  is  some  initial  reluctance 
from  beginning  students  who  have  experience 
with  Turbo  Pascal. 

Ada  is  a  language  that  is  designed  to  reduce 
life-cycle  costs;  this  is  partially  accomplished  by 
attempting  to  discover  software  errors  as  early 
in  the  life-cycle  process  as  possible.  As  a  con¬ 
sequence  of  the  more  extensive  error  checking 
performed  by  an  Ada  compiler,  an  Ada  program 
written  by  a  beginning  student  may  be  more 
difficult  to  successfully  compile  than  its  Pascal 
counterpart;  however  the  Ada  program  is  more 
likely  to  run  successfully.  However,  this  advan¬ 
tage  is  lost  on  some  introductoiy  programming 
students.  The  first  programming  course  typi¬ 
cally  terminates  with  a  demonstration  of  Ada's 
generic  features.  This  characteristic,  coupled 
with  Ada's  exception  handling,  tends  to  convert 
even  the  strongest  Pascal  proponents. 

However,  most  of  our  students  are  eager  to 
learn  Ada.  They  know  it  is  a  more  modern  lan¬ 
guage  and  one  for  which  there  is  strong  local 
demand  by  prospective  employers.  Students 
also  feel  a  justifiable  sense  of  accomplishment 
as  they  learn  to  use  Ada  in  their  software  pro¬ 
jects. 

A  well  prepared  faculty,  coupled  with  mod¬ 
est  institutional  support,  resulted  in  a  relatively 
painless  transition  to  Ada.  The  "top  down"  ap¬ 
proach  of  introducing  Ada  first  in  upper  level 
courses  and  latter  in  the  intermediate  and  intro¬ 
ductory  levjl  courses  worked  well.  (Feldman1 
provides  several  examples  of  academic  institu¬ 
tions  where  Ada  was  introduced  using  a  "bottom 
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up"  approach).  To  paraphrase  the  old  saw  "you 
don't  have  to  be  a  computer  scientist  to  like 
Ada,  try  it  you'll  like  it" 
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THINKING  IN  Ada  -  HOW  SOME  STUDENTS  EXPERIENCE  THEIR  NEW  LANGUAGE 
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Fort  Belvoir,  Virginia  22060 


ABSTRACT  '  It  has  been  said  that  the  way  we  think  is 
determined  by  the  language  which  we  speak. 
Translation  between  spoken  languages  dees  not  always 
have  a  one-to-one  correspondence.  Confuting 
languages  pose  the  sene  problem  of  precisely  trying 
to  represent  a  real-world  problem  as  a  computer 
algorithm.  The  Ada  programing  language  can  be 
presented  to  students  as  hsving  a  high  correlation 
with  the  real-world  problem  domain.  Packages, 
enumeration,  tasking,  and  exceptions  are  likely  to  be 
new  concepts  tc  the  student  of  Ada,  but  they  can  be 
easily  acquired  through  good  representative  problems. 
Reoogniiing  the  real-world  through  Ada  descriptions 
can  resemble  a  new  naturel  language  fer  students. 
Specific  course  problems  and  program  which 
encapsulate  the  learning  experience  are  described. 
Through  such  experiences  they  will  appreciate  the 
power  of  their  new  language  and  enter  their  career# 
with  confidence. 


INTRODUCTION 

Linguists  have  postulated  thst  how  we  think  is 
determined  by  the  language  which  we  speak.  They  also 
note  that  translation  between  spoken  languages  does 
not  always  have  a  one-to-one  correlation.  A  specific 
example  ia  the  German  word  Gemutlichkeit  (a  special 
coziness)  without  a  single  English  word  to  precisely 
represent  it. 

Computing  languages  pose  the  same  problem. 
Software  engineers  have  the  difficulty  of  trying  to 
precisely  represent  a  real-world  abstraction  in  a 
limited  vocabulary.  Perhaps  the  converse  situation 
is  more  often  the  case  -  that  the  limited  vocabulary 
of  a  computer  language  determines  the  way  we  think  a 
problem  should  be  represented. 

The  Ada  programming  language,  with  its  62 
reserved  words,  can  be  presented  to  students  not  as 
a  limitation  of  expression  but  as  a  gateway  to  better 
and  new  ways  of  representing  the  abstraction  as 
compared  to  other  commuter  languages.  Packages, 
enumeration,  tasking,  end  exceptions  are  likely  to  be 
new  concepts,  tools,  thought  process,  and  vocabulary. 
Ada  can  be  an  enabling  technology  for  the 
increasingly  challenging  software  environment. 

The  existing  applications  for  the  space 
station,  air  traffic  control,  end  Urge  HIS  projects 
are  indicators  of  the  future  of  Ada  and  the  level  of 
hunan  thought  and  real-world  to  computer  language 
translation  reeded  to  solve  them.  Students  ere  told 
that  this  is  the  problem  domain  for  their  chosen 
career.  They  are  told  that  Ada  provides  a  rich 
grammar  which  allows  them  to  exercise  their  power  of 


thought  and  expression.  Through  concrete  and 
successively  more  complex  problems,  they  acquire  a 
measure  of  confidence  that  they  will  be  able  to 
master  the  problem  domain  of  their  future. 

This  paper  draws  on  over  twelve  semesters 
of  teaching  beginning  and  intermediate  Ada  courses 
to  undergraduates.  Specific  course  problems  and 
programs  are  selected  which  represent  a  sanple  of 
the  student  experience  in  this  curriculum.  At  each 
introduction  of  a  new  Ada  tool,  the  transformation 
from  word  to  thought  is  reinforced  through  a  real 
or  futuristic  problem.  Banquet  halls  are  complex 
records  of  various  sue  tables  which  are  themselves 
arrays  with  constraints.  Soda  machines  are  man- 
machine  interface  devices.  The  post  office 
requires  a  program  to  weigh  and  ship  packages 
automatically.  The  result  of  these  exercises  is  an 
increased  ability  to  conceptualize  the  real -world 
in  the  Ada  vernacular.  Students  are  challenged  to 
model  a  football  scoreboard  or  the  instrunent  panel 
of  thafr  ear  or  stereo.  The  color  code  of  a 
resistor  offer#  the  opportunity  to  introduce  'POS 
and  'VAL  attributes  in  a  robotics  application  to 
read  or  paint  it. 

By  mid-semester  one  can  argue  that  the  way 
the  student  thinks  about  a  problem  has  now  been 
altered  by  the  expressiveness  of  the  Ada  language. 
Objects  can  be  stated  as  a  collection  of  simple  and 
composite  types.  New  tools  afforded  by  the 
language  have  elevated  the  plane  on  which  problems 
are  organized  and  solved.  Student  derived  term 
projects  are  the  capstone  of  the  course  and  serve 
•s  •  measure  of  the  breadth  and  complexity  of 
problems  that  the  students  themselves  feel  capable 
of  solving  in  their  new  language. 


PROSLEHS  AND  ALGORITHMS 

Just  like  translating  from  one  natural 
language  tc  another,  translation  between  the  real- 
world  and  a  computer  algorithm  is  not  a  direct 
process.  A  graphic  description  of  this  process  w*3 
presented  by  Ledgard  and  Hareotty1  whereby  real- 
world  objects  and  operations  in  the  problem  domain 
are  converted  by  the  programmer  into  programming 
language  objects  and  operations  In  the  solution 
domain.  A  computer  algorithm  produces  output  data 
which  is  then  interpreted  by  hunsrs  back  into  real- 
world  objects.  From  this  model  cne  can  infer  that 
the  higher  the  level  of  abstraction  permitted  bv 
the  computer  language,  the  easier  one  ean  translate 
between  the  real  and  computer  worlds.  Students  are 
taught  thet  Ada  provides  the  tool*  for  high  level 
abstractions  and  that  objects  can  be  expressed  very 
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directly.  For  example,  a  simple  program  to  mix 
colors  it  presented.  If  the  abstraction  is  to  mix 
blue  and  yellow  to  get  green  than  the  statement 

Resulting_Colcr  :«  Blue  *  Yellow; 

is  a  permissible  statement  where  "+"  is  an  overloaded 
function  for  the  declared  enumerated  type  Color  and 
the  supporting  implementation  algorithm  for  the  new 
function  is  shown  in  Figure  1. 


Figure  1.  Program  to  mix  colors. 


The  teaching  point  here  Is  that  Slue  and 
Yellow  are  truly  values  in  an  enumerated  type  and  can 
be  as  easily  computed  as  one  can  pour  one  gallon  of 
paint  into  another.  In  another  language,  aay 
FORTRAN,  Blue  and  Yellow  would  have  to  be  variable 
names,  converted  to  a  numeric  value,  computed,  looked 
up  in  a  result  table,  and  Green  printed  as  a 
character  string.  This  is  far  removed  from  the  real- 
world  abstraction,  and  through  this  kind  of  example 
the  student  quickly  learns  to  appreciate  the  power  of 
expression  permitted  by  the  Ada  language. 

Students  are  toon  introduced  to  compound  data 
types  through  records  and  arrays  as  a  means  to 
describe  real-world  objects  at  a  high  level  of 
abstraction.  An  early  work  by  Downes  and  Goldsaek* 
for  a  hospital  patient  monitoring  system  is  a 
formidable  esse  study  and  discussed  with  the 
students.  It  presents  high  levels  of  abstraction  and 
considerable  depth  of  decomposition.  Records  and 
arrays  composed  of  other  records  and  arrays  permit, 
for  example,  the  retrieval  cf  the  permitted  upper 
blood  pressure  limit  among  other  factors  for  the 
patient  in  bed  13  of  the  intensive  care  unit  by  using 
the  dot-notated  expression 

Intensive_Care_Uni  t(  13).  Safe_Rar»ges.  Upper.  Systolic 


decompose  a  problem.  Practical  exercises  described 
later  allow  the  student  to  gain  experience  in  this 
technique.  Tools  for  "industrial  strength" 
programs  are  early  in  the  making. 


LEARNING  TO  SPEAK  Ada 

The  rudiments  of  expressing  oneself  in  a 
computer  language  are  not  unlike  a  spoken  language. 
At  the  same  time  that  the  notions  of  top-down 
design,  abstraction,  decomposition,  and  parallelism 
are  introduced,  the  student  must  also  learn  from 
the  bottom  up  the  syntax  and  semantics  of  their  new 
language  as  one  must  learn  the  spelling,  grammar 
and  meanings  of  a  spoken  language.  It  is 
instructive  to  observe  how  s  young  child  with  many 
ideas  is  frustrated  at  it  struggles  to  use  new 
words  in  an  unfamiliar  grammar.  Classroom 
experience  has  shown  that  students  need  and  desire 
to  write  real  code  that  compiles  and  executes  at 
the  same  time  that  they  are  learning  concepts, 
design  techniques,  and  the  salient  readability, 
portability,  reliability,  end  maintainability 
tenets  of  Ada.  A  single  viewgraph  of  the  62 
reserved  words  of  Ada  helps  to  alleviate  any 
earlier  preconceived  notion  that  Ada  is  a  vast  and 
complex  language.  After  all,  they  are  told,  only 
•tsif,  res,  and  xor  are  not  English  words  ard  even 
they  are  self-evident  or  require  only  little 
explanation.  All  other, reserved  words  support  the 
high  level  of  abstraction  that  Ada  permits,  and 
through  experience,  like  speaking  a  language,  the 
actions  or  semantics  they  represent  will  become 
second  nature. 

An  immersion  into  the  syntax  is  also 
immediately  called  for.  A  quick  ualkthrough  of 
Appendix  E  in  the  language  reference  manual,  or  the 
equivalent  in  many  textbooks,  is  necessary. 
Confidence  can  be  built  by  a  simple  introduction  to 
the  Bsckus-Kaur  Form  (BNF)  where  the  meaning  of  the 
symbols  for  denoting  a  definition,  :»  for 

assignment,  I  ]  for  0  or  1  occurrence,  {  >  for 
1  or  more  occurrences,  and  J  for  alternation  are 
sufficient  to  understand  and  decipher  all  of  Ada's 
grammar.  Students  find  it  not  too  challenging 
after  all  to  determine  how  to  verify  that  the 
identifier  R2D2  is  permissible  but  3CPO  is  not,  or 
similarly  how  2_000_00C  is  an  optional  form  of 
2000000  for  readability,  but  why  .03  is  not  an 
allowed  decimal  number  representation.  Practice 
and  testing  allow  students  to  soon  mester 
definitions  such  as  for  the  case  statement. 

case_statement 
case  expression  ia 
{iBsen  choice  {  |  choice}  «> 
sequence_of_statements> 

Such  mastery  is  necessary  to  test  new  ideas  for 
abstraction  and  debug  incorrect  assumptions  for 
challenging  problems  Ister. 


Through  this  and  other  such  examples,  students  easily 
gresp  the  concept  of  complex  data  types  where  the 
components  of  records  and  arrays  can  be  constructed 
from  other  complex  types  until  an  atomic  level  is 
reached.  This  permits  the  student  to  visualize  at  a 
high  level  of  abstraction  and  develop  skills  to 


AN  Ada  SAMPLER 

Familiarity  with  the  problem  domain  eases 
the  transition  to  writing  programs  in  Ads. 
Consequently,  example  problems  are  best  understood 
when  they  are  part  of  the  real-world  experience  of 
the  student.  When  introducing  the  fact  thBt 
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enunersted  types  car  have  values  which  are  overloaded 
<a  value  declared  in  sure  than  one  type)  this  at 
first  nay  seen  fcreig.i  or  ambiguous.  Since  most 
students  have  taken  a  general  course  in  chemistry  and 
are  familiar  with  the  periodic  table  of  elenv.nts, 
overloading  the  value  Ne  for  the  element  neon  can  be 
instructive,  keen  fa  both  a  noble  atom 

type  Noble_Atom  ia  (He,ke,Ar,Kr,Xe,Rn); 

and  a  period  2  atom 

type  Period_2_Atoo  is  <ll,Be,8,C,M,0,F,Ke); 


The  Dashboard 


All  students  are  well  acquainted  with  the 
automobile.  Some  are  more  Involved  with  the 
technology  than  others.  The  instrument  panel  of 
automobiles  are  highly  diverse.  Some  ere  simple, 


some  are  arrayed  (ike  alrcrcft  cockpit*.  Some  are 
analog,  some  are  digital.  Student*  react  very 
favorably  and  are  often  highly  challenged  to 
describe  as  a  record  in  Ada  the  details  of 
switches,  lights,  gauges,  and  knobs  on  the 
dashboard  of  their  cars.  Taken  as  a  unit,  the 
dashboard  is  a  relatively  high  level  of 
abstraction,  as  is  the  autemobile  itself. 
Students,  after  having  been  intro&ced  to  arrays, 
records,  and  numeric  types,  return  interesting  end 
varied  homework  assignments  when  given  this  task. 
They  seem  to  enjoy  (as  far  a*  a  student  can  er.joy 
homework)  their  ability  to  express  s  complex  real* 
world  object  in  Ada  and  begin  to  appreciate  the 
translation  process  between  the  automotive  and 
computer  languages.  Figure  2  Is  an  actual  student 
submission  for  this  homework  assignment,  complete 
with  radio/cassette  and  graphic  equalizer. 


Football  Scoreboard 


With  such  type*  of  assignments,  it  Is  fair  , 
to  test  thesa  concept*  on  examinations.  The 
footbell  scoreboard  design  problem  tests  the 
ability  of  the  student  to  model  this  abstraction 
also  as  a  record,  using  array*  with  array 
aggregates  and  a  record  for  the  clock  as  named 
component*  in  the  record.  The  probtem  statement 
and  solution  are  shown  in  Figure  3. 
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Figure  3.  Football  Scoreboard 
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Sometimes  it  is  useful  to  supplement  the 
course  with  unfamiliar  subjects  end  introduce  other 
branches  of  science  and  engineering  as  part  of  the 
student  experience  in  the  Ada  curriculim.  Fewer 
students  have  taken  electronics  than  chemistry  before 
a  programming  course.  Passing  out  a  handful  of 
resistors  and  asking  what  the  color  code  represents 
can  add  a  new  dimension  to  program  design,  livens  the 
class,  and  anticipates  the  future  of  software 
applications.  The  resistor  robot  provides  such  an 
experience  as  described  in  Figure  4. 
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Student  program  assignments  cannot  usually 
be  very  large  given  the  time  available  in  a  one 
semester  course.  And  yet  stixients  should  be 
introduced  to  topics  and  experiences  germane  to 
Ada.  Programming  in  the  large  is  such  a  topic. 
Some  day  as  professional  programmers,  they  could  be 
one  of  tens  or  hundreds  of  programmers  or  a 
project.  Ada  applications  con  exceed  millions  of 
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Figure  4.  Resistor  Robot  Problem 


Figure  5.  Automated  package  mailer. 


147  11th  Annual  National  Conference  on  Ada  Technology  1993 


lines  of  code  and  tears  of  programmer*  will  be  needed 
to  write  this  code.  A  single  project  could  employ 
msny  subcontractors  and  could  be  geographically 
dispersed  hundreds  or  thousands  of  miles  apart. 
Scull  programs  to  teach  this  point  can  be  used  In  the 
classroom.  The  post  office  problem  i*  designed  to 
describe  the  functionality  of  a  new  package  stalling 
machine.  The  package  specification  is  provided  by 
the  instructor.  It  provides  the  interface  between  a 
student  writing  the  application  code  in  procedure 
called  '‘main"  and  the  student  writing  the 
isplemcntaticn  of  the  package  specification  in  the 
package  body.  Separate  compilation,  compilation 
order,  Ir.'ormaticn  hiding,  and  programming  team 
independence  are  the  learning  experiences  hera  as 
presented  in  Figure  5. 

Rendezvous  with  the  Soda  Machine 


Parallel  processing  with  Ada's  task 
facilities  is  a  new  dimension  in  programing  for 
almost  all  undergraduates.  !t  is  perhaps  the  most 
conceptually  challenging  learning  experience  in  an 
Ada  course.  Six  of  sixty-two  reserved  words  in  Ada 
are  devoted  exclusively  to  the  task  mechanism.  Yet 
the  notion  of  parallelism  is  manifested  all  around 
the  real-world.  Bank  tellers  are  "serving"  tasks, 
customers  are  "user"  tasks.  Sometimes  a  "rendezvous" 
takes  place  between  the  two  or  sometimes  such  a 
communication  is  “guarded"  or  “timed."  There  are 
queues  of  customers  and  multiple  service  requests. 
The  new  vocabulary  of  task,  abort,  entry,  accept, 
select,  and  terminate  takes  on  meaning  and  the  BMF 
tools  decipher  the  grammar  for  definitions  such  as 


selective_wait 

select 

t  Wien  condition  *»  ] 
select_aiternative 
<  or  (  Wien  condition  ■>  ] 
select_alternatlve  > 

(  else 

sequence_of_statements  ] 
end  select; 


Once  again  a  familiar  situation  puts  the 
student  more  at  ease  when  tackling  a  new  language 
construct.  After  all,  humans  can  be  represented  as 
tasks  and  so  can  machines.  Students  encounter  soda 
machines  daily  and  sometimes  hourly.  Pushing  a 
button  to  make  a  selection  is  a  common  man-machine 
interface.  It  ia  a  rendezvous  with  a  machine  task 
which  "accepts"  a  selection  or  guards  a  selection 
"when"  the  beverage  choice  ia  empty  (  a  status  tight 
is  illuminated  to  highlight  this  condition).  Soda 
machines  may  even  be  smart  in  the  future  and 
communicate  the  time  to  restock  to  the  vendor  via  a 
modem.  Allow  the  student  to  conceptualize  this 
notion  of  a  parallel  process,  add  a  bit  of  fiction, 
and  the  student  may  often  embellish  the  minimum 
homework  requirement.  The  written  statement  of  the 
problem  and  a  solution  (a  at  Figure  6. 


ft  cold  b^trige  machine  often  mi  idle 
All  selection*  giMUlly  hav*  a  li?ht  which  la  lit  whan  • 
particular  aalaction  la  not  available.  ft  customer  who  chooses 
that  aalaction  anyway  gate  a  NULL  raault,  and  m:*%  **r* 

another  aalaction  or  no  selection.  when  all  liahit  ere  lit*  tha 
machine's  rtf ritaration  unit  and  pow*r  ataya  on,  and  tn*  vendor 
restocks  tha  machine  on  a  achadula  oaaad  on  hiatonea’  data  for 
rataa  of  consumption.  Thla  sooetimea  raaulta  in  cuatomar 
frustration  aa  wall  it  lost  revenues  for  tho  vendor  if  tha 
historical  rates  of  consumption  do  hot  Patch  raal  daaand. 


A  asoart*  cold  beveraot  paehina  could  reduce  frustration* 
increase  rawam»as,  conserve  enary y*  and  govern  all  of  tha 
m*  chinas  intsrnal  fwnctiona.  It  would  omploy  an  embedded 
microprocessor  for  those  purpose**  it  could  ba  ceuplad  to  a 
comwcnlce  t )  om  link  which,  whan  sensing  that  me  machine  ia  a*Pty 
(all  selection  liahts  lit),  would  notify  me  vender  i 
headquarters  of  Its  e«epty  status,  block  tha  slot  for  coin 
inttrtion,  and  thar  turn  it*  ovn  powar  off. 


“Ubjuikbcdcrii' 


Tow  ara  roqmrad  to  ooulata  tho  cold  bavaraaa  machine  by 
a  pain  procedure  (parent  task!  with  two  siblmo  taaka, 
""*  -n,»>-h  siwilatee  the  arrival  and  customer  aalaction  of  a 
T*.  °f  not  bo  •''•liable,  and  a  second  task 

*iirh  aiat.itM  the  cold  bavoraqa  nachlna  accaptanc*  of  tha 


idilrh  simulate*  the  _  _ _  _ _ _ _ „t 

.-nd  ®utpyt“  •  ••,l*9a  to  o  file  according  to 
altlnq  poroai  action  based  of  tha  aalaction  (either 
■otninf  or  tha  type  have rape  dispanaad).  Output  toe  aalaction 
U*ht  statue  (boolean)  before  each  cuatooor  aalaction. 

*iu  Ttrt.toi  mo  nrt  xoi  - 

pceceduts  Mil  li 

type  KVmci  ia  (COLA,  ORANGE,  CMfll) 
i  fiu  mil 

3'Ckefa  NVUUCf  XO  ia  new  EVDNSRATION  10 (BEVERAGE) i 
HCkafatNPTT  UCniO  la  new  I NUMERATION  IO(iOQLSAN|  |  * 

Me  umicijo,  I*>TT_UCIT_:0| 

teak  uvmet_cniMUi 

leak  Itvmsc  PACOCCER  ia 
entry  ITUJi 
entry  SELECT  COLij 
entry  Se«CT~o*an0R| 

••try  nucT’iuri, 
end  acviaacc.pSooqcui 

u'»  body  umieiaeokio«i  ia  tape  rater 
iaak  body  •KVMACi.yjBOOCEa  if  aaparator 
baylR 

CAIATf  (FILE  ->  LAA)  SOL, 

boot  •>  oerr  Fils, 

HAMS  •>  •Ull.SOL'If 
SET  OCTPVTILAM  SOL)  | 

ItvIUGIJUDDCtl.  START) 
and  NAZWf 

aapar ate (HAIR) 

teak  body  U VI RACE  CONSUME  ia 
CS01CS  1  array  (l?  ID  of  StvtRftCE 
I*  (It II 919  ->  COLA. 

317111  »>  ORANGE, 

41114(11  •>  GAAPI) | 

bat  la 

far  INDEX  la  ClOICt 'RANGE  low* 
eawa  CS01CE (INDEX)  ia 

whan  COLA  •>  BEVERAGE  PRODUCER.  mtCT  COLA} 

Whan  ORANGE  •>  »rVEAACl"p»OOOCEA.»ELtCT''ORAMGt| 

Wbea  GRAPE  •>  BEVEAA£X_PRDDUCXR.  RXLECT~CIU.PI  j 
ufce*  atkara  •>  nufli 
and  eaaer 
and  loopr 
as  c apt lea 

■ban  TAStlNG_EM*oa  •>  PVT  LINE  (*EEVEAAdt  MCI  INI  HOT  AVAILABLE*)  I 
uhan  atkara  •>  PVT  LINE (*facapt lea  raised  la  CONSUMER  task.*), 
a  ad  ikvrJU0E_00NA0NiIi 

separate imaim)  !  ... 

COLA  COURT, 

cuaSt  coon,  ! 

RNPTT.LSCRT  i  array  (BEVERAGE)  af  BOOLEAN  ■-  (PAINE  ,  PALES  .PALS!)  | 
baa  In 

NXM  UNSO) ,  j 
J^apt  START/  ! 

far  inoci  in  acvcAAOt  leap 

POT (X RBtS ) I  pure*  ENPTT  LIGHT 
RBR_LlRf| 
and  loapi 
NCR  UKtl 

if  wmuan 

•elect 

•*»•»  bet  KNPTT  LIGHT  (COLA)  •> 

•ceapt  SELECT  COU  do 

DISPERSED*)  |  REN  L2«i 
5®1**  «WR»!  i-  CCLA  COURT  -  It 
if  cOla  count  a  s  Caen 
**m_u«TrtcoLA>  ip  nuii 
ana  Ify  i 
•bd  SELECT  COLA/ 

•f 

whan  SNPTY  LICIT (COLA)  •> 

"•c»rt  stuler.coi*!  -  *>  .uiM 

mo  mi  «»m  licit  tou»s«)  •> 

,11107  Sum  „ 

MIM»»l»*ll  »«»  Ll.lt 
'•  «*»*«  COUNT  -  J, 
l»  OMfct  COl/NT  •  ,  lUn 
<|(«JT».lIS,T(OM)ICll  |.  TUI, 

«n,  nun  ouki, 

«  , 

m*n  iNrrr  Liciiioiuiici]  .> 

Illln.OWU,  -  4.  Mtttt, 

whan  net  EMPTY  /  XCKT(CMPX)  •> 
accept  SELECT  Shape  do 

KV  LlNXr 

GMPE  COW?  i  •  GRAPE  COUNT  -  1/ 

COUNT  •  a  then 

^JJJ-WCbrtCbhPE)  IP  TRUE i 

and  SELECT  CRAPE, 

•r 

wh#M  EMPTTLl CRT (GRABS)  •> 

*n,  :.c1c:n,,itZcT-5""-  -  ^  -'-m 

and  loop) 

PVT  LINK *itVtAACE  NACR1HE  IMPTT*'t 

"trlrltD  »  «MT0C,-), 

PUT^UMCt  COIN  SLOT  BLOCKED,  POWER  OPF*)/  ' 


it  POTUMPTT^UCNTriNhfl))/ 


(TROE,  TRUE,  TRUE)  than  as  It  r  and  if. 


and  SEVIRAGE_PROOOCEBt 


Figure  6.  Soda  machine  problem. 
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After  completing  homework  problems  and 
laboratory  exerefees  of  the  type  above,  students  ere 
tasked  to  choose  a  term  project  of  their  own  liking. 
A  aeries  of  design  reviews  are  conducted  by  the 
Instructor  who  approves  the  project  and  the 
commencement  of  coding.  An  interim  code  walkthrough 
is  conducted,  and  (hopefully)  the  student  submits  a 
working  program  by  the  end  of  the  course  which 
emulates  a  moderately  complex  system.  Historically, 
term  projects  are  between  S00  and  1000  lines  of 
source  code.  Some  Include  graphical  interfaces.  One 
such  project  expanded  the  soda  machine  with  counting 
change,  portraying  the  status  lights  changing  state, 
and  a  sods  can  dispensed.  A  partial  listing  of  some 
projects  includes  the  following  system  emulations: 

Automatic  Bank  Teller 
Crewless  Tank 

State  Lottery  Game  \ 

Drone  Aircraft  Target  Identifier 
Antenna  Tuning  System 
Towers  of  Hanoi  Graphics  Game 
Fast  Food  Ordering  System 
Helicopter  Autorotation  Simulator 

The  term  projects  represent  the  culmination 
of  what  the  student  has  learned,  and  as  importantly, 
how  the  student  identified  with  the  new  language.  It 
manifests  how  the  student  now  thinks  of  the  real* 
world  in  algorithmic  form.  Time  is  allocated  in  the 
course  for  students  to  give  an  oral  presentation  and 
terminal  execution  of  their  project  to  the  instructor 
and  the  rest  of  the  class.  Often  there  are  questions 
and  challenges  from  the  audience.  There  Is  a  sense 
of  satisfaction  with  the  Ada  skills  acquired.  It  is 
evident  during  the  presentations. 


CONCLUSION 

The  Ada  language  is  an  expressive  tool  for 
modeling  the  real-world  problem  domain.  Student  can 
experience  their  new  language  In  ways  that  pa  ilel 
spoken  languages  through  a  combination  of  top  down 
and  bottom  up  design  lectures  and  coding 
requirements.  Ada's  close  affiliation  with  high 
levels  of  abstraction  affords  the  student  with  the 
ability  to  conceptualize  the  problem  domain  and  map 
It  to  an  Ada  design.  learning  Ada  becomes  an 
enabling  technology  for  the  student.  The  language  is 
closely  affiliated  with  the  natural  way  of  thinking 
about  a  problem.  Problem  examples,  homework,  labs, 
and  term  projects  can  provide  a  fertile  test  bed  for 
students  to  experience  their  new  language  and  build 
confidence  in  their  programming  abilities. 
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Integrating  Ada  Into  Realtime  Laboratory  Teadairsg 


Dr.  Rcdbey  J.  Bchlmann 
Department  of  Electrical  and  Computer  Engineering 
Valparaiso  University,  Valparaiso,  IN 


Abstract 

This  paper  describes  a  succession  of 
attempts  to  get  Ada  teaching  started  in  an 
engineering  curriculum.  The  target  of  realtime 
systems  teaching  is  described.  Early  experiences 
with  compilers  and  tools  are  included  as  a  measure 
of  how  to  proceed.  Classroom  experiences  are 
documented  with  the  notable  positive  and  negative 
results  exposed.  Curriculum  revision  to  introduce 
Ada  as  an  enhancement  for  laboratory  teaching  is 
described.  Finally  the  plans  to  use  Ada  as  a 
realtime  language  to  target  MC68000  based 
applications  are  presented. 

Introducing  Change  In  Engineering 

Change  comes  hard  b  Engineering 
teachbg.  New  ideas  are  often  mistrusted  until  they 
have  met  the  test  of  time.  To  say  it  more  succinctly 
Engineering  Educators  are  among  the  most 
conservative  professionals  in  the  world.  They  are 
quick  to  remark  how  old-fashioned  thbgs  are,  but 
arc  slow  to  make  a  really  significant  change.  The 
changes  are  left  to  scientists  and  a  few  maverick 
research  and  development  oriented  engbeers.  Then 
Engbeers  are  quick  to  jump  on  the  bandwagon, 
once  the  band  is  b  full  swbg. 

In  the  area  of  softwa/e,  the  Engbcer  is 
suspicious  of  any  price  for  software  until  it  is  shown 
to  solve  the  tedious  problems  of  design  and  analysis 
that  are  a  large  part  of  Engineering.  Thus, 
programs  like  ANSYS  or  SPICE  can  command  a 
high  price  while  a  compiler  is  of  little  or  no  value. 
Further,  the  development  of  software  is  given  little 
or  no  value  by  Engbeers  who  are  not  familiar  with 
the  process  of  software  system  development. 
Software  piracy  on  the  other  hand  is  not  largely 
practiced  among  Engbeers  probably  because  of 
their  strong  adherence  to  a  code  of  ethics. 

Thus  for  Engbeering  to  embrace  Ada  as  a 
teaching  language  was  a  particularly  difficult 
proposition.  Any  compiler  is  viewed  as  expensive 
and  Ada  was  doubly  or  triply  so  during  the  early 
Ada  development  times  at  Valparaiso  University. 


Some  effort  had  been  spent  to  move  the 
Engbeerbg  Departments  into  a  software  design 
mentality.  Until  1979  software  was  taught  pretty 
much  b  a  syntax  and  semantics  style  only,  with  little 
or  no  design  process  taught.  Then  the  design 
teaching  began  and  shortly  thereafter  the  switch 
from  FORTRAN  to  pascal  occurred  to  allow  more 
expressive  power  relative  to  the  design  process. 

This  author  and  a  close  colleague  gabed  a 
considerable  experience  teaching  the  software 
design  process  to  the  entire  freshman  class  of 
Engineers.  From  our  vantage  point  in  an  Electrical 
Engbeerbg  department,  the  cost  of  software  was 
seen  to  take  an  bordbatc  bite  out  of  a  project 
budget.  This  cost  was  being  borne  largely  because 
of  the  inefficient  and  often  beffective  design 
practices. 

As  that  teaching  matured,  the  Computer 
Science  faculty  watched,  and  after  two  years  of 
successful  leaching  with  pascal  the  more  mature 
faculty  decided  that  they  could  follow  suit  and 
change  the  CS  curriculum  to  the  p  acal  language. 
Engbeering  faculty  b  other  departments  watched 
suspiciously  until  they  saw  the  capabilities  of  the 
students  emerging  from  the  introductory  teaching. 
The  new  student  was  able  to  design  programs  and 
implement  them  b  pascal  readily.  They  soon 
learned  that  implementation  b  FORTRAN  was  also 
quite  possible  from  the  new  design  practices. 

So  some  Engbeers  stayed  hooked  bto 
FORTRAN  even  if  it  meant  using  the  terribly 
befficient  PC-based  FORTRAN  compilers.  Slowly 
they  maneuvered  toward  pascal,  some  actually 
acceptbg  programs  written  in  pascal  b  the  upper 
division  courses.  But,  as  they  shifted,  they  began  to 
place  great  worth  on  the  programs  written  for  them 
by  these  new  students  with  better  capabilities  than 
their  predecessors.  The  faculty  started  to  place  a 
value  on  the  code  and  so  began  to  "own*  it  as 
though  it  were  irreplaceable.  In  hindsight  this 
should  have  been  addressed  as  it  began.  For  now 
the  situation  became  one  where  a  highly 
conservative  group  had  placed  a  self  determined 
value  on  something  and  while  many  were  attached 
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to  FORTRAN  most  were  hooked  on  the  quality  of 
the  pascal  programs  their  students  had  created  for 
them.  Experience  is  truly  the  best  teacher. 

Realtime  Systems  Teaching  Emerges 

In  the  mean  time,  Electrical  Engineering 
began  to  develop  some  good  capacity  for  realtime 
system  work.  Realtime  in  this  environment  meant 
that  some  physical  system  was  connected  to  a 
computer  and  would  respond  dcterminably  to 
stimulus  from  a  computer  program.  Much  work 
was  done  in  C  and  assembly  language  ana  in  our 
laboratory  all  the  work  was  done  using  MC6809 
processors.  Slowly  a  capacity  to  do  the  realtime 
work  in  the  pascal  language  was  identified  as  a  good 
idea.  A  compile  time  and  run  time  system  was 
developed  for  programming  embedded  systems  in 
pascal.  This  was  developed  by  student  and  faculty 
effort  and  is  still  a  viable  system  for  such  work. 

During  this  stage  a  critical  event  occurred 
with  the  author  being  aopointed  to  an  ASEE 
summer  fellowship  at  NASA-CALTECH  Jet 
Propulsion  Laboratory.  During  that  summer  of 
1981  Ada  was  beginning  to  take  off  for  Department 
of  Defense  processes.  The  supervisor  for  that 
summer  appointment  was  Dr.  Ed  Ng  who  had  been 
active  in  the  development  of  Ada  and  was  among  its 
strong  proponents  within  NASA.  Needless  tc  say 
that  ASEE  appointment  had  a  strong  influence  to 
begin  looking  at  Ada  as  a  next  step  after  pascal  in 
the  laboratory. 

Reading  and  study  soon  uncovered  some 
unhappy  features  of  pascal  for  software  engineering. 
Separate  compilation  was  severely  lacking  in  pascal. 
It  was  possible  to  use  pascal  include  features,  but 
that  does  not  really  allow  the  gains  possible  from 
dividing  a  large  program  into  separate  parts  for 
development.  While  some  pascal  dialects  addressed 
this  deficiency,  the  realtime  development  system  in 
use  had  no  prospect  for  correcting  the  problem. 

The  method  implemented  for  realtime 
control  in  pascal  had  been  a  set  of  procedures  and 
functions  which  allowed  for  addressing  of  hardware 
memory  locations  and  fielding  of  interrupts.  The 
fact  that  the  pascal  features  were  working  well  was 
of  great  benefit  to  the  students.  The  further  fact, 
that  the  pascal  extension  which  allowed  those 
features  was  developed  locally,  was  a  serious 
deterrent  to  convincing  students  that  high  level 
language  was  preferred  over  assembly.  After  all. 


the  extensions  were  not  easily  ported  to  other  pascal 
compilers.  Thus  the  representation  clause,  so 
obviously  included  in  Ad3,  showed  it  to  be  much 
superior  to  the  pascal  in  use. 


Necessary  Early  Experiences 

The  effort  to  bring  Ada  into  the  curriculum 
then  began  with  an  earnest  search  for  a  compiler  to 
support  our  efforts.  At  the  same  time  the  teaching 
of  Ada  as  a  language  was  planned.  A  pertinent 
paper  by  Jean  Sammet  pointed  out  the  need  to 
focus  on  more  than  the  language  features  [1]. 
Rather  there  was  a  pressing  need  to  move  our 
introductory  teaching  into  a  more  philosophical 
direction.  This  resulted  in  a  formalizing  of  a 
taxonomy  of  sequential  program  as  described  in 
Bohlmann  [2], 

The  compiler  search  resulted  in  acquisition 
of  a  non-validated  compiler  running  on  a  PC.  The 
compiler  was  well  documented  and  the  company 
corrected  our  difficulties  with  telephone  and  updates 
as  needed.  R  &  R  Software  provided  us  with  a 
packaged  JanusAda  compiler  b  ten  copies  [3].  This 
allowed  us  to  provide  Ada  compilation  services  to 
students  at  our  public  sites  in  and  around  our 
computer  center.  The  cost  of  the  compiler  was 
borne  by  the  budget  in  our  department,  and  so 
needed  to  be  contained  preventing  us  from  puttbg 
the  more  robust  compilation  services  on  our  central 
time  sharing  system. 

With  Ac  effort  to  teach  Ada  underway,  the 
limitations  of  this  early  compiler  were  quickly 
uncovered.  The  students  routinely  attempt  to  use 
the  features  of  Ada  as  documented  in  the  Ada 
Language  Reference  Manual  or  LRM  [4],  They 
equally  routinely  misuse  those  features  leading  to 
some  confusion.  This  is  where  the  study  and 
experience  of  the  faculty  is  a  critical  factor.  Such 
problems  as  small  symbol  table  space,  and  program 
and  data  size  limitations  on  PCs  were  part  of  our 
learnbg  process. 

These  problems  were  not  unexpected. 
What  is  of  interest  is  that  the  scope  of  problems 
that  the  faculty  felt  comfortable  assigning  to 
students  increased  dramatically  with  the  prospect  of 
success  because  of  the  features  of  Ada.  It  was  now 
possible  to  do  a  divided  development  with  separate 
compilation.  During  the  first  project  the  students 
were  divided  bto  groups  of  two  or  three.  Each 
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group  was  assigned  responsibility  for  a  part  of  the 
design.  Class  wide  planning  sessiors  were  used  to 
divide  the  problem  and  assign  the  parts.  The  next 
class  meeting  was  devoted  to  discussing  preliminary 
specifications  as  developed  within  the  gioups. 
These  specifications  were  evaluated  for 
completeness  and  service  quality  to  the  project. 
Cnee  the  specifications  were  agreed  upon,  each 
team  had  the  assignment  to  code  the  specification 
and  compile  it  into  a  common  library.  This  step 
proved  to  be  a  pertinent  catalyst  for  the  teams  to 
produce  body  text  to  support  their  own 
specifications. 

Though  the  compiler  in  use  at  th.;  time  had 
some  limitations,  the  students  were  able  to  progress 
rapidly  into  proper  design  for  testability  and 
reusability.  These  features  continue  to  be  important 
features  of  software  engineering.  Further,  the 
difficulty  with  the  compiler  fostered  a  language 
lawyer  attitude  among  the  better  students.  This 
attitude  was  the  key  factor  in  extraction  of  the 
pertinent  semantic  features  to  bo  applied.  As  the 
teams  interacted,  questions  arose  about  how  to 
express  algorithm  or  data  requirements.  The 
language  lawyers  among  us  would  quickly  come  up 
with  solutions.  In  retrospect,  that  capability  was 
necessary  for  the  success  in  our  efforts.  A  perfect 
compiler  may  in  fact  not  have  enabled  us  to  develop 
that  capacity. 

This  first  experience  added  valuable 
knowledge  into  the  environment  at  Valparaiso 
University.  The  students  felt  like  they  were  learning 
and  doing  some  serious  large  program  work.  The 
faculty  felt  like  they  were  learning  and  leading 


now  a  Verdix  company,  offered  a  price  competitive 
deal  on  a  compiler.  Looking  primarily  for  a 
validated  compiler,  cost  was  the  other  factor  in 
choosing  the  next  compiler.  Meridian  University 
Support  provided  us  with  evaluation  copies  of  their 
PC-based  Ada  compilers.  The  compilers  solved  all 
of  the  problems  that  had  earlier  limited  our  use  cf 
Ada.  The  version  4.0  AdaVantage  compiler  solved 
the  symbol  table  problems  and  the  extended 
memory  compiler  solved  the  large  program  space 
limits  when  needed.  Not  unexpectedly,  the  new 
compiler  brought  some  idiosyncrasies  of  its  own. 

Shortly  after  selecting  the  Meridian  Ada  4.0 
compiler  as  the  replacement,  Meridian  announced 
two  products  of  interest  to  us.  One  was  their 
AdaStudent  which  provided  a  validated  Ada 
compiler  with  the  limitation  that  no  library  linking 
was  allowed.  This  simply  required  that  all  code  be 
compiled  into  the  same  library.  For  small  programs 
and  syntactic  learning  this  was  superb.  Superb 
because  of  its  price.  Our  one  time  fee  of  $1000 
allowed  us  to  distribute  ten  copies  of  AdaStudent  to 
our  students  for  use  on  their  personal  computers. 
We  also  had  the  larger  compilers  for  the  more 
central  sites  and  so  the  combination  worked  well. 
The  second  product  that  appeared  then  was  the 
AdaZ  product  which  later  changed  name  to 
OpenAda.  The  cost  of  this  complete  compiler  was 
dropped  to  $149  and  several  students  and  faculty 
opted  to  purchase  their  own  compiler.  This 
compiler  had  an  integrated  environment  for  editing 
and  compiling  with  language  directed  edit  functions. 
It  showed  some  direct  competition  for  functionality 
with  the  Turbo  Pascal  product  in  use  in  our 
freshmen  course. 


students  into  the  philosophical  approach  already 
recognized  as  the  appropriate  method  of  software 
teaching.  While  the  over  all  functionality  of  the  first 
project  was  never  realized,  the  students  who 
participated  uniformly  rated  that  as  their  best 
programming  experience  to  date.  In  the  years  that 
have  passed,  most  of  those  involved,  students  and 
faculty,  have  come  to  a  much  larger  experience. 
This  was  a  good  start. 

Beyond  that  first  project,  the  JanusAda 
compiler  was  used  until  further  budget  was 
allocated  to  upgrade.  One  upgrade  was  purchased 
and  donated  to  the  school  by  the  faculty  involved, 
but  finally  it  was  time  to  search  for  a  new  compiler. 
In  the  years  that  had  passed  the  compiler 
technology  had  progressed.  Several  validated 
compilers  were  available  for  PC  work.  Meridian, 


Continued  use  of  the  compiler  started  to 
uncover  some  of  it  failings.  During  one  process  of 
development  we  discovered  that  dynamic  memory 
unchecked  deallocation  was  dysfunctional.  We  also 
experienced  some  problems  with  order  of  the 
compilation  of  stubbed  sub-programs.  The  most 
recent  upgrade  solved  the  problem  of  memory 
control  and  as  of  this  writing  compilation  order 
problem  is  being  investigated  by  Meridian.  Even 
with  the  problems  encountered  the  Meridian 
compilers  served  us  and  continue  to  serve  our  needs 
in  a  more  than  adequate  way. 

Classroom  Experiences  to  Build  on 

The  first  of  the  classroom  projects 
attempted  with  Ada  centered  in  a  course  or. 
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simulation.  Past  work  on  event  driven  simulation 
provided  a  platform  for  developing  an  event  driven 
simulator  for  digital  systems  work.  The  goal  of  the 
project  was  to  apply  Ada  to  a  real  problem  that  had 
testable  results. 

This  project  afforded  the  experience  of 
separate  compilation,  with  team  efforts  for 
specification  and  body  development,  and  with 
language  lawyer  attitudes  as  described  earlier.  The 
basic  concept  of  a  generic  insertion  queue  was  a 
principle  feature  of  this  work.  Students  were 
delighted  to  learn  of  generic  capacity  to  allow  for 
full  featured  programs. 


Implemented  in  R  &  R  JanusAda  the 
project  faltered  with  the  large  data  needs  and 
expansive  programs  created  by  novice  Ada 
programmers.  A  good  experience  j  allowed  for 
further  work  on  Jades  with  a  later  group  of 
students.  It  is  a  manager’s  responsibility  to 
maintain  the  documentation  and  code  for  such  a 
hiatus  in  activity.  The  one  year  i  layover  was 
managed  by  the  faculty  and  allowed  for  even  more 
programming  learning  as  the  problem  was 
resurrected  later. 


Creative  Course  Development 

Teaching  in  this  way  was  not  a  routine 
thing.  The  courses  on  Ada  were  housed  in  a  catchall 
Topics  in  Electrical  and  Computer  Engineering  title. 
The  Ada  topic  was  germane  to  the  |  course  with 
different  problems  chosen  by  students.  Another 
feature  of  this  course  is  that  it  is  not  a  fixed  number 
of  credits.  In  the  four  semesters  that  Ada  was 
taught  under  this  rubric,  semester  credits  of  one, 
two,  and  three  were  all  used  for  student  records. 
Each  student  agreed  on  a  level  of  work  with  credit 
commensurate  with  the  level.  Projects  allowed  for 
varied  participation  and  students  were  able  to  fine 
tune  the  workload  and  credits  to  their  curriculum 
needs.  Minimum  requirements  of  simple  programs 
ensured  basic  knowledge  for  the  poorest  performing 
students.  This  topics  course  is  documented  in  the 
CREASE  6.0  catalog  [5]. 


and  Bunt  [6]  for  the  first  few  years  and  then  shifted 
to  Finger  and  Finger  [7]  for  a  little  better 
Engineering  flavor.  Students  worked  with  central 
time  sharing  computers  and  at  the  best  times,  with 
selected  students,  projects  were  as  complex  as 
image  processing  and  separate  modular  compilation. 
Turbo  pascal  came  into  vogue  toward  the  end  of  life 
of  the  course  and  became  the  compiler  of  choice 
because  it  supported  the  Ada-like  feature  of  units. 

The  proposal  was  to  take  that  course,  select 
a  group  of  students,  and  in  one  section  of  five, 
convert  the  course  to  the  language  Ada.  In 
concession  to  the  FORTRAN  users  the  pascal 
sections  used  a  textbook  with  some  FORTRAN  in 
it.  The  Ada  course  used  a  well  written  text  by 
Putnam  Texe!  [8].  This  book  introduced  package  as 
the  base  concept  and  built  on  it  throughout. 

Projects  in  the  Ada  course  were  chosen  to 
exemplify  Ada  and  at  the  same  time  parallel  the 
projects  in  the  control  sections.  Exception  handling 
for  input  output  processes,  instantiation  of  generic 
input  output  routines,  overloading  and  other 
features  of  Ada  were  necessary  introductory 
material  overed  in  projects.  A  final  project  using 
a  graphics  utility  library  was  attempted.  This 
however  faltered  because  of  failures  in  the  graphics 
package. 

Students  were  selected  based  on  a  self 
selecting  process.  Experience  in  high  school  with 
programming  other  that  Basic  was  required. 
Predisposition  to  a  computer  intensive  Engineering 
curriculum  and  career  was  suggested.  With  this 
simple  guideline  and  some  advisor  assistance  a 
group  of  17  freshman  were  identified  as  the  Ada 
guinea  pigs. 

The  performance  for  programming  and  the 
perceived  capability  of  the  students  after  the  course 
was  positive.  The  philosophical  approach  that  had 
been  tried  and  true  in  the  previous  pascal  courses, 
excelled  in  the  new  Ada  section.  The  performance 
of  the  students  in  the  following  course  would  be  the 
test  of  how  well  the  approach  actually  worked. 


Experience  behind  us,  a  proposal  was 
prepared  for  the  College  of  Engineering  to  do  an 
experiment  with  our  freshmen  course,  Introduction 
to  Algorithms  for  Computing.  This  course  had  a  rich 
history  of  teaching  with  clear  goals  and  syllabus.  It 
had  begun  with  FORTRAN  aud  progressed  to 
pascal.  The  textbooks  used  began  with  Tremblay 


Evaluating  the  Experiment 

The  second  course  on  Algorithms,  taught 
outside  of  Engineering,  in  the  Mathematics  and 
Computer  Science  Department  followed  in  the 
immediate  next  semester  after  the  Introduction 


3  11th  Annual  National  Conference  on  Ada  Technology  1993 


/ 


course.  This  course  enrolled  students  from  three 
introductory  courses.  First,  students  from  the 
introductory  CS  course  were  enrolled.  Secondly  the 
pascal  sections  of  the  introductory  engineering 
course  fed  students  into  the  second  level  algorithms 
course.  And  now  for  the  first  time  the  third  group, 
students  whose  first  experience  was  in  Ada,  were 
enrolled  with  the  others. 

The  pascal  language  was  strongly 
entrenched  in  this  Algorithms  II  course  and  posed 
some  challenge  for  the  Ada  students.  While  the 
Engineering  faculty  felt  they  were  prepared  to 
continue  their  studies,  the  CS  faculty  balked, 
unwilling  to  do  comparative  studies  with  two 
languages.  The-  Ada  students  requested  help 
sessions  for  the  parallel  comparisons  allowing  them 
to  do  pascal  work.  The  author  agreed  to  the  help 
sessions  under  the  proviso  that  the  CS  faculty  attend 
to  guide  them  in  the  right  direction.  At  first  this 
fell  like  the  Ada  teaching  had  failed  to  be  broad 
enough.  However,  as  the  help  sessions  progressed 
the  student.,  themselves  took  over  the  study,  and  in 
the  manner  that  I  had  hoped  fer,  they  used  the 
philosophy  that  they  had  learned  studying  Ada  to 
extrapolate  the  pascal  needed  to  excel.  The  CS 
faculty  also  began  to  get  a  positive  exposure  to  Ada 
as  the  students  would  conclude  that  they  needed  to 
find  a  "different"  method  to  do  in  pascal  what  they 
knew  readily  how  to  do  in  Ada.  As  they  worked 
out  the  detail  they  would  implement  iheir  ideas  in 
Ada  and  then  study  how  to  implement  the  same 
algorithms  in  pascal.  The  CS  faculty  finally 
accepted  the  Ada  solutions  as  solved  problems  and 
the  Ada  students  were  successful  in  the  course. 


Success  Builds  Interest 

A  continued  effort  for  ^topics  courses 
allowed  for  o  wide  variety  of  experience  with  Ada. 
Among  the  first  topics  to  be  studied  in  detail  was 
tasking.  This  was  chosen  because  of  the  strong 
interest  in  realtime  multi-processor  applications. 
Applications  such  as  this  are  a  regular  part  of  the 
production  systems  in  the  steel  mills  in  Northwest 
Indiana.  As  a  consultant,  the  problems  encountered 
were  largely  with  the  tasks  and  interprocessor 
communications  when  multiple  processors  were 
involved.  Thus,  some  study  in  the  area  of  tasks  was 
of  interest. 

One  student  in  the  tasking  topic,  chose  to 
implement  an  array  of  tasks  to  solve  the  classical 


Towers  of  Hanoi  problem.  He  chose  to  use  block 
graj  aics  for  a  two  dimensional  representation  of  the 
soli  :  on  as  it  progressed.  The  general  organization 
s  solution  was  to  make  each  ring  a  task  and 
each  channel  for  moving  a  ring  on  the  screen  a  task. 
The  rings  were  then  free  to  r'»ove  as  the  program 
could  identify  a  place  for  a  ring  to  move  and 
allocate  a  channel  task  to  carry  the  ring.  The  Ada 
source  code  is  not  particularly  difficult  and  is 
available  from  the  author. 

Another  topic  dealt  with  extending  the 
functionality  of  Ada  to  matrix  operations.  Students 
were  assigned  the  problem  of  creating  a  set  of 
overloading  get  and  put  routines  to  get  and  pet 
vector  and  malri;  data.  An  interesting  note  here  i:; 
'hat  the  students  were  all  taking  Ada  as  a  second 
language  and  were  weak  in  there  notions  of 
overloading.  Though  we  had  discussed  overloading 
in  class  the  first  cut  solutions  of  all  hut  a  few 
students  failed  to  use  the  procedure  names  of  get 
and  put  to  overload  the  generic  operators  with  ones 
having  vector  or  matrix  parameters.  After  a  br>ef 
discussion  in  class,  the  students  were  quite  receptive 
to  the  suggestion  that  the  proper  solution  was  to  use 
the  names  get  and  put  as  overloaded  operators.  A 
further  feature  suggested  by  students  that  completed 
the  input  output  package,  added  lh>,  parameters 
standard  to  the  generic  input  output  procedures  for 
numeric  types.  The  fore,  aft,  and  exp  parameters 
were  added  as  was  a  parameter  to  control  the 
display  of  indexes  as  output  was  presented.  Default 
values  were  included  to  make  the  routines  conform 
as  much  as  possible  to  the  generic  input  output 
routines  documented  in  the  l.RM. 

The  prompting  index  operation  was  most 
useful  for  interactive  output  of  array  data.  Since 
much  of  the  programming  done  was  for  interactive 
use,  the  prompt  was  selected  by  student-  as  an 
important  feature.  Thus,  the  overall  package  for 
vector  and  matrix  input  and  output  was 
implemented  and  the  students  were  then  assigned 
the  problem  of  creating  a  matrix  and  vector 
calculator.  Students  less  able  to  create  such  a 
program  were  allowed  to  do  a  sequence  of  get  and 
put  operations  with  computations  in  between.  The 
matrix  and  vector  operations  were  acquired  in  a 
matrix  package  authored  by  Dr.  Roger  Lee  and 
moved  by  ftp  from  the  Sim»el20  Ada  repository  [91. 

During  the  time  that  the  matrix  input 
output  operations  were  under  development,  another 
section  of  students  in  the  same  semester  accepted 
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the  assignment  of  perusing  the  network  archives  for 
Ada  packages  of  use  to  our  programming  and 
teaching.  Though  Valparaiso  University  was  using 
a  limited  BITNET  connection  at  the  time  the 
resourceful  students  were  able  to  discover  and 
retrieve  several  useful  artifacts.  For  graphics 
interactions  a  set  of  mouse  drivers  in  Ada  was 
retrieved  and  these  same  students  also  retrieved  the 
array  operations  package  for  their  fellow  students  in 
the  other  section.  One  of  the  special  features  of 
Ada  is  that  the  packages  and  others  that  followed 
were  directly  compiled  and  linked  into  our 
developing  system.  This  was  a  rather  important 
point  for  students  who  were  just  starting  to  see  the 
big  picture  in  large  program  development.  They 
realized  that  the  programmer  does  not  necessarily 
need  to  create  all  of  the  code  for  a  project.  Som 
code  can  be  acquired  by  network  or  purchased  from 
vendors  to  the  job  done  more  rapidly.  With  this 
also  comes  an  awareness  for  software  license  and 
propriety  of  use. 

Brief  comments  are  in  order  for  two  other 
Ada  projects  done  in  the  topics  area.  The  first  was 
done  for  a  student  who  also  was  a  bicycle  designer 
and  fabricator.  The  students  in  the  section  with  him 
agreed  to  create  a  bicycle  design  program  to  select 
from  standard  parts  and  create  a  bicycle.  Special 
parts  were  also  included  to  allow  for  custom  frame 
sizing  and  custom  wheel  development  and  such. 
The  overall  success  of  that  project  was  limited. 
Students  working  in  that  section  were  not  as  well 
prepared  to  take  on  an  Ada  task  at  the  beginning  of 
the  semester  and  almost  half  of  the  semestet 
elapsed  before  the  program  design  could  begin 
Starting  this  late  with  a  design  for  the  program,  the 
code  never  reached  beyond  multiple  group 
specifications  being  compiled  successfully. 
Implementation  of  only  a  few  of  the  bodies  limited 
the  testing  of  the  program  to  only  a  very  few 
functions.  Students,  even  sc,  reported  confidence 
that  the  large  program  they  had  started  was  well 
designed  and  on  the  brink  of  completion. 

The  other  project  undertaken  was  to 
attempt  to  create  an  Ada  package  for  a  DASH-8 
and  DASH-16  data  acquisition  system  embedded  in 
i  PC.  The  approach  by  this  sophomore  group  was 
to  first  choose  between  creating  new  code  and 
translating  the,  original  pascal  drivers.  They  opted 
to  translate  the  pascal  drivers,  largely  because  of 
their  familiarity  with  pascal  and  less  familiarity  with 
hardware  features  of  things  like  data  acquisition 
systems.  Again  the  completion  level  was  limited  but 


the  student  satisfaction  was  high. 

A  New  Approach  with  a  New  Tool 

With  the  third  year  of  topic  teaching  a  new 
software  product  was  acquired.  This  tutorial 
product,  NSite  Ada  [10],  allowed  for  students  to 
study  topics  in  Ada  in  a  computer  directed  manner. 
The  limited  budget  however,  put  some  constraints 
on  the  use  of  the  built-in  examining  functions. 
Students  needed  to  record  their  own  quiz  scores 
and  keep  track  of  their  own  progress.  Even  so  the 
students  progressed  rapidly  into  a  good  knowledge 
of  Ada  and  software  engineering.  The  directed 
learning  was  an  excellent  approach  to  instilling  the 
philosophy  that  had  come  to  be  a  part  of  our 
teaching.  The  material  itself  was  organized  into 
chapters  that  followed  the  organization  of  the  LRM. 
The  studcnls  studied  the  material  in  sequence  from 
start  to  finish. 

Often  times  the  students  would  get  together 
as  groups  and  pursue  a  chapter  in  the  tutorial 
material  quizzing  and  discussing  the  matters  as  they 
went  They  then  would  joint'y  solve  programming 
assignments  and  experiment  with  new  ideas  based 
on  the  programs  completed.  The  style  of  learning 
which  resulted  was  superior  to  the  lecture  and 
discussion  style  that  had  been  in  use.  With  this 
style  the  interaction  between  faculty  and  student 
moved  to  a  joint  investigative  phase.  Now  students 
could  assist  in  raising  the  level  of  language 
understanding  which  the  faculty  was  pursuing.  The 
more  rapid  acquisition  of  language  capability  by  the 
students  also  allowed  for  more  direct  programming 
assignments. 

The  NSite  product,  as  first  acquired  serves 
quite  well  despite  a  significant  number  of 
typographical  and  content  errors  in  the  tutorial 
material.  The  NSite  tool  is  at  this  time  unde*-  re- 
evaluation  at  Valparaiso  as  we  consider  a 
competitive  product  LearnAda  [11]  which  covers  the 
same  need.  Independent  of  which  tutorial  product 
is  used,  the  computer  based  tutorial  will  -provide  a 
good  method  of  introducing  the  language.  It  also 
provides  a  rapid  access  to  reference  material  both 
in  the  tutorial  text  and  by  having  a  copy  of  the 
LRM  on  line. 

With  students  studying  Ada  by  tutorial, 
classroom  time  war.  free  to  pursue  specific 
programming  topics.  One  topic  that  was  studied  as 
a  means  of  understanding  the  Ada  run  time  support 
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package  was  task  preemption.  The  Meridian 
compiler  in  use  provides  for  task  preemption  and  so 
run  time  controlled  time  slicing  and  priority 
assignments  for  tasks  were  usable.  Simple 
programs  were  written  that  displayed  time  slicing 
and  task  priority  behavior  with  preemption  enabled 
and  with  preemption  disabled.  The  results  were  not 
surprising  for  the  experienced  faculty,  but  were 
powerful  examples  for  students  just  starting  to 
consider  how  a  computer  could  be  useo  in  a  multi¬ 
tasking  manner.  The  amount  of  time  required  to 
do  the  example  programs  with  the  class  would  not 
have  been  available  if  the  class  time  would  have 
been  used  for  Ada  information  lectures.  The 
computer  based  tutorial  enabled  these  studies. 

A  Prolect  That  Works 

Experience  builds  confidence  and  so  it  is  in 
the  case  of  experiences  using  Ada.  The  philosophy 
of  software  engineering  and  the  use  of  Ada  became 
ingrained  with  the  faculty.  As  Ada-9X  promised  to 
come  into  existence,  the  experience  with  Ada-S3  was 
continuing.  During  the  Fall  1992  semester  the  most 
recent  assignment  was  made  to  a  group  of 
Computer  Science  students  studying  Ada  under 
Engineering  faculty  supervision.  These  students 
were  given  the  assignment  of  building  a  part  of  the 
old  JADES  project  in  a  new  way.  In  order  to  do 
event  driven  simulation  an  ordered  queue  of  events 
to  be  processed  needed  to  be  supported.  The 
assignment  given  to  the  group  was  one  of  building 
an  Insertion  Queue  which  contained  elements  and 
invoked  a  user  supplied  order  relation  to  insert  new 
items  in  the  Queue  for  later  removal  in  order.  This 
has  direct  application  for  sequencing  events  during 
simulation. 

The  creation  of  a  generic  procedure  to 
provide  insertion  queue  capability  proved  to  be  the 
most  interesting  assignment  to  date.  The  technical 
task  was  not  that  difficult.  What  was  interesting  is 
that  the  students  were  Junior  and  Senior  level  and 
had  a  deeply  ingrained  pascal  flavor  to  the  their 
style.  Specific  discussion  about  overloading,  generic 
objects  and  instantiation  details  was  a  regular  part 
of  class  meetings.  Students  began  the  semester  with 
pascal  knowledge  and  used  the  NSite  tutorial  to 
gain  Ada  knowledge.  It  took  about  five  weeks 
before  the  final  form  of  the  generic  queue  could  be 
envisioned  by  the  students. 

Once  they  had  a  clear  view  of  the  problem 
it  was  divided  into  three  parts  with  Enqueue, 


Dequeue,  and  QueueSize  naturally  dividing  the 
problem.  The  procedure  Enqueue  and  Dequeue 
and  the  function  QueueSize  were  created  as  stubbed 
separate  bodies.  This  allowed  for  complete  syntax 
free  compilation  prior  to  finishing  the  detailed 
algorithm.  It  also  allowed  for  a  complete 
replacement  of  the  internal  storage  method  for  the 
sorted  queue,  should  performance  become  an  issue 
in  the  use  of  the  Insertion  Queue.  Students  were 
divided  into  three  groups  to  complete  the  stubs  and 
the  whole  package  was  brought  together  with  a  test 
program  four  weeks  before  the  end  of  the  semester. 

Testing  uncovered  a  problem  with 
unchecked  deallocation  which  was  corrected  by  a 
compiler  upgrade  which  was  purchased  earlier  and 
had  arrived  about  a  week  before  it  was  needed. 
Some  call  that  just-in-time  delivery  while  in  our  case 
it  was  just-dumb-Iuck  timing.  Another  matter  that 
was  uncovered  in  testing  was  discovered  as  the 
separate  bodies  were  compiled.  The  library 
manager  does  not  update  the  body  executable  code 
for  a  separate  body  when  that  body  is  compiled 
after  the  parent  unit.  The  order  of  compilation  is 
being  looked  into  by  Meridian  and  we  expect  that  it 
will  be  resolved  cleanly.  In  the  mean  time  we  can 
assume  that  what  we  are  trying  to  do  may  be 
outside  the  scope  of  the  compiler  and  constrain  our 
compilation  order  to  not  recompile  separate  bodies 
without  first  compilmg  the  parent. 

The  Insertion  Queue  was  completed  and 
tested  with  a  variety  of  queue  element  types  and 
differing  order  relations.  It  includes  the  exceptions 
Full_Queue  and  EmptyQueue.  This  package  is  the 
first  generic  package  at  VU  that  was  completed  well 
and  with  full  functionality  and  good  documentation. 
The  assignment  was  smaller  than  previous 
assignments,  but  the  problem  was  solved  in  a  more 
elegant  manner  than  previous  solutions.  Finally,  the 
tools  of  Ada  were  available  to  the  students  because 
the  faculty  had  enough  grasp  of  the  language  to 
coach  them  properly. 

Curriculum  Revision  to  Include  Ada 

As  the  Ada  language  experience  developed, 
the  curriculum  at  Valparaiso  University  was  under 
revision.  Four  disciplines  of  Engineering  worked  to 
create  a  curriculum  that  would  best  serve  each.  As 
part  of  that  work  a  serious  review  of  programming 
teaching  was  done.  Within  Computer  Engineering, 
Ada  was  selected  as  the  language  for  realtime 
embedded  systems  teaching.  This  lead  to  a  decision 
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to  supplant  pascal  from  the  early  curriculum  and 
use  Ada  as  the  first  language.  It  also  results  in  an 
impact  on  the  second  and  third  year  programming 
courses  that  need  an  Ada  revision. 

The  other  disciplines  of  Civil,  Mechanical 
aid  to  a  lesser  extent  Electrical  Engineering 
reached  the  conclusion  that  teaching  about 
programming  was  much  less  important  in  their  new 
curriculum.  This  reflects  the  thinking  that  programs 
needed  for  discipline  specific  activities  are  available 
commercially,  and  little  or  no  programming  will  be 
needed  to  apply  them  correctly.  There  is  even  the 
sentiment  that  when  programming  is  required  it  can 
be  employed  from  knowledgeable  persons  on  an  as 
needed  basis. 

Those  conclusions  might  be  better 
understood  if  one  reviews  the  results  of  the 
curriculum  discussions.  Pascal  was  deeply 
entrenched  and  pascal  tends  to  make  programming 
easy  as  compared  to  using  Basic  or  FORTRAN. 
Thus  the  Engineering  professors  were  in  a  better 
situation  with  pascal  than  they  had  ever  been. 
Secondly,  there  was  a  strong  sentiment  that 
FORTRAN  should  be  taught  to  engineers.  The 
arguments  for  FORTRAN  reduced  to  "There  are  a 
lot  of  FORTRAN  programs  running."  and  "Most  of 
the  other  schools  are  doing  it."  While  these 
arguments  are  irrefutable,  they  do  not,  in  the 
authors  opinion,  warrant  continuing  with  a  language 
that  has  successfully  completed  its  service. 

There  also  surfaced  a  sentiment  that 
Valparaiso  University  College  of  Engineering  should 
not  be  the  leader  in  the  area  of  Engineering 
Software  teaching  revision.  Noting  that,  the 
decision  was  finalized  that  Computer  Engineering 
faculty  will  teach  programming  for  Computer 
Engineers  and  Electrical  Engineers  and  that  Civil 
and  Mechanical  Engineers  will  take  computer 
literacy  courses  specifically  about  software  in  their 
discipline.  This  result  is  now  being  implemented 
and  for  the  time  being  seems  to  be  the  correct 
deci&ic  1  for  our  school. 

Thus  the  Computer  Engineering  course, 
Algorithms  for  Computing,  based  on  Ada,  will  be 
taught  for  die  first  time  in  the  fall  of  1993  to  the 
first  wave  of  Sophomore  students  studying  in  the 
revised  curriculum.  They  reach  this  first  course  as 
Sophomores  because  we  chose  to  introduce 
hardware  concepts  first  in  the  second  semester 
Freshman  year  immediately  after  the  major  is 


declared  in  Computer  Engineering.  Using  logic 
design  as  the  basis,  it  is  expected  that  benefits  will 
accrue  for  software  engineering  teaching  in  the  first 
programming  course. 

Directly  coupled  to  all  of  the  Ada 
development  is  the  decision  to  use  Ada  to  teach 
embedded  systems  design.  The  Computer 
Engineering  laboratory  sequence  and  two  elective 
courses  address  the  issue  of  high  level  language 
usage  for  embedded  systems  in  various  ways.  Pascal 
was  in  use  for  ten  years  and  served  well  as 
described  earlier.  With  the  MC6809  processor,  and 
a  locally  extended  pascal  native  code  compiler, 
students  were  able  to  create  significant  products  for 
course  work  and  for  sponsored  development 
projects.  In  one  case,  the  students  were  able  to 
demonstrate  the  value  of  high  level  language 
development  over  assembly  language  for  a  small 
company.  The  dramatic  decrease  in  expected 
development  time  was  a  convincing  experience  for 
the  project  Engineer. 

With  pascal  working  so  well,  it  was  no  easy 
decision  and  is  no  easy  task  to  work  toward  a  major 
technology  shift.  Yet,  with  the  better  featuies  found 
in  Ada  and  the  better  epu  capacity  of  the  MC68000, 
the  time  was  right  to  make  some  changes.  The 
vendor  support  from  Motorola  and  from  Ada 
compiler  vendors  is  growing  as  we  make  the 
necessary  effort  of  contacting  them  and  exposing 
our  needs.  This  continues  to  suggest  that  we  are 
making  progress. 

The  shift  to  the  MC68000  is  now  complete 
with  the  installation  of  MC68000  based  systems  for 
software  and  hardware  development.  These  systems 
were  built  in  conjunction  with  the  University  of 
Toronto  where  they  were  developed.  The  features 
of  the  boards  include  2Mbytes  of  memory,  both 
AUI  and  BNC  sthernet  ports,  four  RS-232  ports, 
printer  ports  land  parallel  I/O  connectors.  The 
network  connection  allows  the  boards  to  be 
supported  from  our  growing  workstation 
environment.  | 

Presently  the  programming  for  laboratory 
and  course  work  is  being  done  in  C  and  assembly 
language.  Programs  are  compiled  or  assembled  on 
a  Sun  3/60,  an  MC68020  based  workstation.  The 
compilers  and  libraries  are  part  of  the  package 
received  from  University  of  Toronto.  Object 
modules  are  loaded  into  the  target  system  by  ftp 
connections  via  the  ethernet.  It  is  also  possible  to 
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load  object  modules  from  the  TTY  ports. 

While  C  is  not  the  language  of  choice,  it  is 
the  only  compiler  at  VU  at  this  time  capable  of 
generating  MC68000  cods.  Negotiations  and 
financing  are  in  progress  to  place  an  Ada  compiler 
on  the  workstations  and  to  develop  the  methods  of 
compiling  Ada  code  and  loading  it  by  ftp  connection 
as  is  currently  being  done  with  C.  Such  operation 
is  available  for  purchase  and  is  actively  being 
pursued. 


Ada  Blossoms 

The  blossoming  of  Ada  at  Valparaiso 
University  has  been  a  long  process.  Ada  is  not  yet 
in  full  bloom  though  critical  junctures  are  past. 
Recent  agreements  assure  better  funding  in  the 
future  and  support  for  faculty  development  to  a 
higher  level  has  recently  been  ftmded.  The  demand 
for  Ada  learning  continues  to  grow  among  our 
student  body.  That  demand  may  also  grow  in  the 
work  place  as  the  students  and  vendors  get  the  Ada 
message  to  the  managers. 

There  is  no  substitute  fer  interaction  with 
colleagues  in  other  places  who  are  doing  Ada 
teaching.  Thus,  the  support  for  attending  ASEET 
and  ANCOST  sponsored  meetings  in  past  years  and 
the  recent  support  for  two  of  us  to  attend  Tri-Ada 
is  both  useful  and  necessary.  The  effective  return 
on  the  investment  in  our  case  was  greatly  enhanced 
by  participation  in  tutorials  at  the  meetings.  Over 
the  years,  tutorials  by  Engle  and  Dominice  [12], 
Cook  and  Vega  [13],  and  Rogers  [14]  were  all 
attended  and  have  contributed  significantly  to  the 
positive  Ada  experience. 

Now  the  plans  are  frozen  which  will  allow 
us  to  work  toward  a  goal.  The  obstacles  of 
development  have  been  removed  and  the  new  Ada 
based,  Algorithms  for  Computing  course  is  being 
readied.  The  impact  on  the  second  level  courses  is 
anticipated.  The  compiler  for  laboratory  use  will 
grow  out  of  the  current  funding  mechanism. 

So  once  again  it  is  time  to  begin.  Begin, 
because  up  until  now  Ada  teaching  was  an 
experiment  which  was  providing  great  experience. 
Now  the  students’  learning  and  career  development 
will  depend  on  the  results.  This  is  a  serious  matter 
and  we  do  not  take  it  lightly  as  we  begin  teaching 
introductory  programming  with  the  language  Ada. 


Ada-83  is  now  ten  years  old.  We  have  followed  it 
and  used  Ada-83  and  as  we  begin  teaching  it  in  our 
mainstream  curriculum,  we  expea  to  migrate  to 
Ada-9x  easily  and  painlessly. 

Conclusion 

Ada  knowledge  is  not  easy  to  acquire. 
Experience  is  needed  to  build  the  confidence  in 
faculty  that  Ada  is  neither  bigger  nor  smaller  than 
other  programming  languages  when  beginning 
teaching  is  considered.  There  is  a  limited  amount 
of  information  that  can  be  imparted  to  beginning 
students.  It  is  important  that  the  information  be 
well  selected  and  well  presented  to  foster  a  quest 
for  knowledge.  With  Ada,  software  engineering  and 
philosophical  approaches  to  programming, 
Computer  Engineering  students  at  Valparaiso 
University  will  be  quite  ready  for  the  future 
development  and  application  of  computer  hardware 
and  software. 
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.SUMMARY 

The  U.S.  Navy  has  embarked  on  the  Next  Generation 
Computer  Resources  (NGCR)  program  to  fulfill  its 
need  for  standard  computing  resources.  The  program 
revolves  around  the  selection  of  interface  standards  in 
six  areas.  One  of  these  areas  is  project  support 
environments  (PSEs).  The  projects  supported  by  the 
environments  develop,  enhance  or  maintain  computer- 
based  systems  or  products.  These  interface  standards 
should  be  useful  for  projects  focused  primarily  on 
software  development,  hardware  development  or  the 
concurrent  development  of  hardware  and  software. 
They  will  include  support  for  Ada.  This  prper 
discusses  the  approach  and  plans  for  the  selection  of 
these  PSE  standards  and  the  issues  that  must  be 
addressed  for  the  effort  to  be  successful. 


The  U.S.  Navy  has  embarked  on  the  Next  Generation 
Computer  Resources  (NGCR)  program  to  fulfill  its 
need  for  standard  computing  resources.  The  program 


takes  an  open  systems  architecture  approach  and 
revolves  around  the  selection  of  interface  standards  in 
six  areas.  One  of  these  areas  is  project  support 
environments  (PSEs).  The  projects  supported  by  the 
FSEs  develop,  enhance,  or  maintain  computer-based 
systems  or  products,  including  those  in  which  Ada  is 
used.  These  interface  standards  should  be  useful  for 
projects  focused  primarily  on  software  development, 
on  hardware  development  or  on  the  concurrent 
development  of  hardware  and  software. 

BACKGROUND 

The  Navy  has  a  long  history  of  developing  and  using 
standard  computer  products.  When  computer 
technology  was  in  its  infancy,  the  Navy  wielded 
significant  influence  in  the  market,  setting  its  own 
requirements  and  developing  its  own  computer 
designs,  including  Instruction  Set  Architectures 
(ISAs).  Standard  computer  implementations  (i.e.r 
buying  "boxes")  and  upward  compatible  ISAs  have 
been  the  foundation  of  the  Navy's  computer  policy. 
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This  policy  has  been  motivated  by  the  fact  that 
software  can  adapt  a  common  computer  design  to 
meet  many  different  applications. 

But  the  Navy's  current  computer  standardization 
approach  is  not  technologically  competitive  in  today's 
environment  of  rapidly  improving  technologies.  The 
Navy  acquisition  and  budget  process  takes  a  long  time 
to  field  new  standard  computers,  so  long  that  the 
produced  technology  is  often  old  (compared  to 
commercial  technology)  by  the  time  it  is  fielded.  The 
obvious  logistics  benefits  associated  with  standard 
hardware  are  offset  by  the  inability  to  field  current 
technologies.  In  addition,  the  DoD  in  general  no 
longer  is  a  major  factor  in  the  marketplace  and  cannot 
dictate  what  it  wants  or  needs.  The  fact  that  the 
defense  budget  is  shrinking  means  that  the  Navy  can 
no  longer  afford  to  go  it  alone  and  instead  needs  to 
leverage  off  of  the  commercial  marketplace. 

The  objective  of  the  NGCR  program  is  to  restructure 
the  Navy’s  approach  to  acquisition  of  standard 
computing  resources  to  take  better  advantage  of 
commercial  advances  and  investments.  It  is  expected 
that  this  new  approach  will  result  in: 


Application  of  these  interface  standards  will  change 
the  Navy's  approach  from  one  of  buying  standard 
computers  to  one  of  procuring  commercial  computing 
resources  which  satisfy  the  interfaces  defined  by  the 
standards.  These  standards  will  be  applied  at  the 
project  le’rel  rather  than  a  Navy-wide  procurement 
level. 

PSESWG 

The  effort  to  establish  the  PSE  interface  standards 
was  initiated  at  the  start  of  1991  with  the  inaugural 
meeting  of  the  Project  Support  Environment 
Standards  Working  Group  (PSESWG  -  pronounced 
"peace-wig").  As  with  all  of  the  NGCR  working 
groups,  this  is  a  joint  industry/academia/government 
group  of  technologists  with  backgrounds  in  the 
requirements  for  and  issues  regarding  PSEs.  This 
Navy-led  group  is  committed  to  the  identification  of 
PSE  interface  standards  in  the  form  of  a  military 
standard,  with  an  accompanying  military  handbook,  by 
1998. 

approach 


.  reduced  production  costs  (through  larger 
quantity  buys) 

.  reduced  operation  and  maintenance  costs 

.  avoidance  of  replication  of  Navy  RDT&E 
costs  (for  separate  projects  to 
develop  similar  computing 
capabilities)  and 

.  more  effective  system  integration. 

The  proposed  new  approach  is  an  open  systems 
approach  based  on  the  establishment  of  commercially- 
based  interface  standards  in  six  areas:  multisystem 
interconnects,  multiprocessor  interconnects,  operating 
systems,  database  management  systems,  graphics 
standards,  and  project  support  environments.  This 
open  systems  approach  is  ccnsistent  with  the  trend 
throughout  the  industry. 

The  NGCR  interface  standards  will  be  based  on 
existing  industry  standards  with  multi-vendor  support. 
In  cases  where  existing  industry  standards  do  not  fully 
meet  Navy  needs,  the  approach  is  to  further  enhance 
the  existing  standards  jointly  with  industry.  This  will 
assure  the  Navy  of  a  widely-accepted  set  of 
commercially-based  interface  standards. 


Some  of  the  approach  taken  by  the  PSESWG  is 
dictated  by  the  NGCR  program.  Other  aspects  are 
driven  by  the  necessities  cf  the  PSE  area.  The 
following  are  the  key  elements  of  the  PSESWG 
approach. 

1.  Joint  industry/academia/goverament  working 
group 

All  of  the  NGCR  standardization  efforts  are 
accomplished  by  working  groups  with  strong 
industrial,  academic  and  government  participation. 
The  PSESWG  is  well-balanced,  including  members 
from  the  research  community  as  well  as  the  PSE  user 
community.  It  draws  heavily  on  industry  expertise  as 
well  as  that  available  from  all  facets  of  the 
government.  All  three  services,  the  federally-funded 
research  and  development  centers,  and  the  National 
Institute  of  Standards  and  Technology  (NIST)  have 
been  represented  at  meetings.  This  balance  provides 
technological  strength  while  assuring  the  group  that 
there  is  a  sound  balance  between  the  perceived  Navy 
requirements  and  the  directions  in  which  industry  is 
heading. 
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2.  Standardization  on  interfaces,  not  products 

One  cf  the  keys  to  the  NGCR  program  is  to  get  away 
from  standardization  on  products  and  to  move 
towards  open  systems.  To  achieve  this  means  that  the 
emphasis  must  be  on  interfaces,  services,  and 
protocols,  not  specific  vendor  implementations,  even  if 
those  implementations  have  been  created  according  to 
Navy  specifications.  There  are  plans  to  maintain 
Certified  Product  Lists  for  some  of  the  NGCR 
standards,  and  it  may  be  appropriate  at  times  for  rhe 
Navy  to  make  large  procurements  of  products  that 
meet  the  standards.  However,  the  important  thing  will 
always  be  the  interfaces  rather  than  the  products.  In 
this  way  the  Navy'  can  enjoy  the  benefits  of  new 
technology  and  increased  interoperability  of  its 
systems. 

This  general  NGCR  principle  applies  to  the  PSE 
effort  as  well.  It  is  sometimes  difficult  for  PSE  users  to 
think  of  their  systems  in  terms  of  the  interfaces 
between  the  components.  But  doing  so  is  key  to  being 
able  to  include  the  best  of  the  available  tools  in  Navy 
project  PSEs  and  tc  achieve  productive  integration  of 
the  PSE  components,  even  when  they  are  from  a 
variety  of  vendors. 

3.  Selection  of  existing  industry  standards 

Another  emphasis  in  the  NGCR  program  is  on  the 
ability  of  the  Navy  to  become  a  part  of  the  industry 
marketplace,  thus  being  able  to  take  advantage  of 
industry  innovations  and  advances  in  technology.  To 
achieve  this,  the  program  focuses  on  the  selection  of 
existing  industry  standards  whenever  possible.  Wc  will 
often  find  that  existing  industry  standards  do  not  quite 
provide  all  of  the  features  required  by  the  Navy,  so  it 
is  common  for  the  working  groups  to  become  active  in 
the  industry  organization  responsible  for  a  standard 
that  has  been  selected.  If  there  is  a  firm  requirement 
for  an  interface  for  which  no  viable  industry  standard 
can  be  found,  the  working  group  will  decide  whether 
the  need  is  strong  enough  to  try  to  find  industry 
interest  in  converging  on  such  a  standard.  Only  as  a 
last  resort  will  a  working  group  create  its  own  unique 
interface;  it  will  often  be  preferable  to  simply  defer 
the  requirement  until  an  industry  standard  emerges. 

For  the  PSESWG  this even  more  straightfoiward 
than  for  the  other  groups.  There  is  most  often  little  to 
distinguish  a  DoD  PSE  from  that  required  in  any 
other  setting.  Small  parts  (e.g.,  the  requirements  to 
support  Ada)  may  be  different,  but  they  do  not  affect 
the  essential  nature  of  a  PSE  nor  most  of  the 


interfaces  needed  to  support  PSEs.  The  final  PSE 
standard  is  expected  to  refer  to  new  and  existing 
environment  interface  standards  and  to  be  usable  in 
the  procurement  of  Navy  (and  other)  systems  in  1998. 
The  initial  focus  of  the  PSESWG  is  on  identifying 
those  areas  of  support  environments  that  should  have 
standardized  interfaces  and  for  which  industry- 
accepted  interface  standards  can  be  available  within 
the  project's  time  frame. 

4.  PSESWG  organization 

The  PSESWG  has  been  organized  into  subgroups  and 
teams.  The  subgroups  are:  Reference  Models, 
Available  Technology,  and  Approach.  The  Reference 
Models  Subgroup  is  working  in  cooperation  with  the 
NIST  Integrated  Software  Engineering  Environments 
(ISEE)  effort  to  produce  a  full  environment  reference 
model.  PSESWG  intends  to  use  the  model  for 
identifying  PSE  interface  requirements  and  describing 
PSE  technology.  The  Available  Technology  Subgroup 
is  collecting  and  reviewing  descriptions  of  existing 
environment  interface  technologies.  The  Approach 
Subgroup  is  planning  the  organization  and  operation 
of  PSESWG,  including  procedures  for  the  selection  of 
H  sc  line  standards. 

The  PSESWG  has  recently  organized  teams  which  are 
more  focused  upon  standard  production  and  specific 
technology  areas.  (PSESWG  members  generally 
participate  on  one  subgroup  and  one  team.)  The 
initial  teams  are  Data  Interfaces,  Framework,  and 
Standard  and  Handbook  Writing.  The  Data 
Interfaces  Team  is  tasked  with  investigating  the  data 
interchange  technology  area  and  its  subareas, 
producing  an  interface  requirements  document  for  the 
technology,  and  producing  a  list  of  candidates  for 
selection  as  part  of  the  developing  standard.  The 
Framework  Team  has  tasks  similar  to  those  of  the 
Data  Interfaces  Team  for  the  framework  technology 
area.  The  Standard  and  Handbook  Writing  Team  is 
tasked  with  actually  writing  the  draft  military  standard 
and  draft  military  handbook. 

5.  PSESWG  Standard 

The  Project  Support  Environment  Interface  (PSEI) 
standard  will  not  define  standard  tools  or  tool  sets  for 
use  in  Navy  system  development.  Instead,  the  focus  is 
on  tool  integration  mechanisms  (including 
frameworks),  data  exchange  mechanisms,  and  the 
logical  contents  of  project  data  repositories.  An 
integrated  (harmonized)  set  of  environment  interface 
standards  is  important  in  the  success  of  NGCR. 
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Technically,  the  adoption  of  standards  for  PSE 
interfaces,  services,  and  protocols  will  provide  a  means 
for  better  integration  within  a  PSE  and  better 
interaction  between  different  PSE  implementations. 
Procurement  of  PSEs  will  be  aided  by  making  their 
specification  easier  and  by  lowering  costs  for  common 
PSE  components. 

PROGRESS  AND  ACCOMPLISfnvfENTS 


PSESWG  effort  to-date  has  focussed  on  three  main 
products1 2:  the  Available  Technology  Report,  the  PSE 
Reference  Model,  and  the  initial  selection  of  some 
PSE-related  standards. 


Available  Technology  Report 


This  report  is  a  compendium  of  technologies  that  are 
available  today  that  are  believed  to  have  relevance  to 
the  PSESWG  effort.  Most  of  the  entries  describe 
interface  standards,  both  recognized  and  de  facto, 
although  a  few  describe  products  that  appear  to 
address  aspects  of  interfaces  that  go  beyond  the 
services  provided  by  existing  standards  or  interface 
areas  of  interest  for  which  no  standards  are  known. 
The  technologies  described  are  presented  in  the 
following  categoriesr: 


Task  Management  Services 
User  Interface  Services 
Operating  Systems  Services 
Network  Services 
Framework  Services 
Data  Integration  Services 
(including  General 

Administration, 
Commerce,  and 
Transportation 
Documentation 
Electronic  Design 
Graphics 
Hardware  Design 
Interface 
Description 
Product 


1  All  PSESWG  documents  described  in  this  report  are 
available  by  contacting  the  authors. 

2  The  reader  will  note  that  this  list  of  categories  is  not 
completely  compatible  with  the  categories  in  the 
following  section  from  the  Reference  Model.  This  was 
not  unexpected,  as  the  two  pieces  of  work  proceeded 
in  parallel,  and  the  categories  will  be  reconciled  when 
both  documents  are  mature. 


Description 

Software 

Engineering 

■  Time) 

Data  Repository 
Security  Services 

PSE  Reference  Model 

Before  it  is  possible  to  select  interface  standards,  it  is 
first  necessary  to  understand  all  of  the  interface  areas 
for  which  it  might  be  beneficial  to  identify  standards. 
To  do  this  requires  a  thorough  understanding  of  PSEs, 
both  as  they  exist  in  the  current  state-of-the-practice 
and  as  they  are  expected  to  exist  in  the  future 
timeframe  of  the  military  standard.  The  approach 
PSESWG  has  taken  to  this  problem  is  to  derive  a 
reference  model  for  a  full  environment,  as  no  generic 
one  existed  at  the  initiation  of  the  PSESWG  effort. 
This  reference  model  has  been  based  on  the  work  of 
the  European  Computer  Manufacturers'  Association 
(ECMA)  and  NIST,  which  resulted  in  the  Reference 
Model  for  Frameworks  of  Software  Engineering 
Environments^1!.  These  groups  have  contributed  to 
the  PSESWG  model.  Material  has  also  been  borrowed 
from  the  POSIX  P1003.0  Guide  to  the  POSIX  Open 
System  Environment^.  The  remainder  of  the 
reference  model  originated  with  the  members  of  the 
PSESWG  Reference  Model  Subgroup,  making  use  of 
inputs  from  other  organizations  to  the  greatest  extent 
possible. 

The  PSESWG  Reference  Model  provides  a  catalogue 
of  services  that  covers  the  functionality  expected  of  a 
fully  populated  PSE.  These  services  are  divided,  at  a 
high  level,  into  those  that  are  part  of  the  framework 
and  those  that  are  directly  accessed  by  the  end-user. 
The  Framework  Services,  most  of  which  arc  taken 
from  either  the  NIST/ECMA  reference  model  or  the 
POSIX  model,  are  categorized-*  by: 

Operating  System  Services 
Object  Management  Services 
Policy  Enforcement  Services 
Process  Management  Services 
Communication  Services 
User  Interface  Services 
User  Command  Interface  Services 
Network  Services 


3  As  of  this  writing,  the  reference  model  has  not  been 
completed.  Therefore,  this  list  is  from  version  0.8  and 
some  anticipated  changes  for  version  1.0  and  is  subject 
to  change. 
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which  "obvious"  standards  existed,  thus  making  the 
choice  fairly  simple. 


The  End-user  Sei  vices  are  categorized  by: 

Technical  Engineering  Services 

System  Engineering  Services 
Software  Engineering  Services 
Life-Cycle  Process  Engineering 
Services 

Technical  Management  Services 

Configuration  Management  Services 
Reuse  Management  Service 
Metrics  Services 

Project  Management  Services 
Planning  Service 
Scheduling  Service 
Estimation  Service 
Analysis  Service 
Tracking  Service 
Presentation  Service 

Support  Services 

Common  Support  Services 
Publishing  Service 
Presentation  Preparation  Service 
User  Communication  Services 
Administration  Services 

Once  version  1.0  of  the  reference  model  has  been 
published  (February  1993),  the  next  step  will  be  to  use 
it  to  identify  the  interfaces  that  are  required  by  all  of 
these  services.  That  list  of  interfaces  will  be  culled 
down  to  those  interfaces  for  which  standardization  is 
likely  to  have  a  benefit.  This  list  of  target  interfaces 
will  then  be  prioritized  and  pursued  for  the  remainder 
of  the  duration  of  the  PSESWG. 

InitialSglgCtion  of  Standards 

1 

i 

Because  there  are  so  v^ry  many  PSE  interfaces  for 
which  standardization  might  be  of  interest,  it  was  felt 
that  some  sort  of  start  heeded  to  be  made  on  them, 
despite  the  fact  that  the  reference  model  was  not  yet 
ready.  It  was  agreed  that  there  are  a  number  of  basic 
"platform"  interfaces  that  are  provided  by  existing 
popular  standards  that  could  be  easily  selected  without 
any  detriment  to  the  likely  future  PSESWG  selections. 
These  are  standards  for  such  things  as  operating 
system  and  network  interfaces,  which  do  not  heavily 
influence  the  characteristics  that  distinguish  one  full 
PSE  from  another.  The  PSESWG  only  considered 
making  these  early  selections  in  interface  areas  for 


The  initial  set  of  standards  recommended  for  inclusion 
in  the  draft  PSEI  standard  and  the  interface  areas  they 
address  are: 

P05IX.1  and  POSIX.2  (operating  system) 

X- Windows  (user  interface  protocols;  the 

decision  on  a  toolkit  was  deferred  for 
now) 

FHIGS  (graphics) 

GOSIP  (networks) 

This  set  of  initial  selections  is  being  published  as  a 
laboratory  technical  report  and  will  be  widely 
distributed  throughout  the  Navy  and  to  all  members  of 
PSESWG  and  other  interested  DoD  agencies.  These 
selections  are  the  first  increment  for  the  eventur! 
PSESWG  military  standard,  and  they  will  be  available 
for  anyone's  use.  They  are  documented  in  "Toward  a 
MILjSTD  and  MIL-HDBK  for  Project  Support 
Environment  Interfaces." 

PLANS 

The  target  date  for  the  PSESWG  standard  is  1998. 

The  initial  selections  of  the  whole  group  have  been 
followed  by  the  concentrated  work  of  the  Framework 
and  Data  Interfaces  Teams  to  more  thoroughly 
explore  these  two  areas,  coming  up  with  ways  to  use 
the  reference  model  to  determine  the  interfaces  that 
are  of  interest.  Each  of  these  groups  is  charged  with: 

.  Identifying  the  interface  areas  to  be 
addressed 

.  formulating  requirements  for  tbem 

.  identifying  viable  candidates  for  them 

.  and  conducting  an  in-depth  evaluation 
process  to  determine  the  best 
interface  standard  to  select  for  each. 

These  selections  will  be  reviewed  and  concurred  with 
by  the  whole  PSESWG  and  then  are  subject  to  the 
approval  of  the  NGCR  program  office.  A  military 
standard  with  an  accompanying  military  handbook  will 
be  formulated  and  expanded  as  each  selection  is  made 
and  approved,  resulting  in  a  formal  MIL-STD  and 
MIL-HDBK  that  will  be  submitted  for  formal  tri¬ 
service  approval  late  in  1996. 
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There  are  many  issues  that  need  to  be  addressed  in 
the  course  of  such  an  ambitious  undertaking  as  the 
PSESWG  standard.  Here  are  a  few  that  are  likely  to 
be  of  interest  to  anyone  following  this  work. 

Ada 

The  NGCR  program  is  committed  to  Ada.  All  of  the 
application  program  interfaces  (APIs)4  that  are 
selected  are  expected  to  be  provided  with  Ada 
language  bindings.  However,  the  reality  of  the 
marketplace  is  that  there  are  few  PSEs  in  existence 
today  that  rely  solely  on  Ada  interfaces  of  any  kind, 
and  there  are  even  fewer  bona  fide  standardization 
efforts  that  put  a  significant  emphasis  on  Ada.  Thus 
there  are  at  times  going  to  be  conflicts  between  the 
desire  to  support  Ada  and  the  desire  to  adopt  industry 
standards. 

In  the  case  of  the  PSESWG  this  apparent  conflict 
needs  to  be  further  explored.  On  the  one  hand,  the 
PSESWG  must  clearly  support  the  functioning  of  tools 
intended  to  support  the  development  and  maintenance 
of  Ada  artifacts;  these  include,  for  example,  compilers, 
linkers,  program  libraries,  debuggers,  and  program 
design  language  (PDL)  tools.  But  it  is  not  necessarily 
true  that  all  tools  that  support  the  development  and 
maintenance  of  Ada  artifacts  must  themselves  be 
written  in  Ada  or  dependent  on  Ada  bindings  for  PSE 
interfaces.  On  the  other  hand,  examination  of  the 
marketplace  indicates  that  the  majority  of  work  and 
products  available  (including  the  standards  produced 
by  accredited  organizations)  do  not  often  provide  Ada 
bindings  for  their  interface  standards. 

This  has  put  the  NGCR  program  in  an  awkward 
position.  While  it  is  committed  to  Ada,  it  is  also 
committed  to  helping  the  Navy  become  active 
participants  in  the  PSE  marketplace,  which  requires 
adopting  industry  standards  that  are  more  often  in  'C. 
Thus  the  PSESWG  (and  NGCR  program  in  general) 
have  had  to  accept  that  both  Ada  and  'C  language 
bindings  will  be  important  and  will  need  to  be 
supported  by  the  interface  standards  that  are  chosen. 


4  APIs  are  a  subset  of  all  possible  interfaces:  all  APIs 
are  interfaces,  but  there  are  other  kinds  of  interfaces 
that  do  not  require  the  procedural  syntax  of  a 
programming  language  and  so  are  not  provided  as 
APIs. 


The  environments  community  is  very  diverse;  it  could 
even  be  said  to  be  in  a  state  of  upheaval.  Being  a  very 
young  community'  (generally  less  than  15  years),  there 
is  little  agreement  on  definition  of  terms.  There  is 
even  a  lack  of  consensus  on  the  definition  of  what 
encompasses  an  environment  or  what  its  predominant 
components  are  (or  should  be).  There  are  many 
relevant  standardization  efforts,  but  few  have  been 
originated  by  the  environments  community  itself. 
There  is  a  distinct  lack  of  coordination,  which  is 
compounded  by  the  fact  that  researchers  from 
disciplines  other  than  software  engineering  (e.g., 
CAD,  manufacturing  engineering,  and  concurrent 
engineering)  are  converging  on  similar  ideas  without 
seeming  to  realize  the  work  that  the  software 
engineering  community  has  already  done.  An  example 
of  the  diversity  is  found  in  the  use  of  languages,  where 
DoD  -related  experimentation  and  implementations 
often  make  use  of  Ada,  but  industry  makes  extensive 
use  of  'C  (including  further  divergence  into  new 
variations,  such  as  C  +  +  ),  while  the  academic 
knowledge-based  community  often  goes  for  LISP.  In 
order  for  real  progress  to  be  made,  especially  in 
directions  that  will  make  interface  standards  possible 
and  useful,  such  efforts  need  to  come  together  and 
approach  the  problem  in  a  coordinated,  cooperative 
manner.  It  is  hoped  that  one  effect  of  the  PSESWG 
reference  model  work  will  be  to  provide  a  backdrop 
against  which  such  cooperation  can  take  shape. 

frcfiling 

Standards  often  have  options  associated  with  them.  It 
is  also  possible  that,  when  combining  more  than  one 
standard  in  an  effort  to  satisfy  the  needs  of  a  whole 
system,  there  will  be  slight  incompatibilities  between 
some  of  the  standards.  These  incompatibilities  must 
be  addressed  to  make  the  suite  work  together.  The 
process  of  examining  the  individual  standards  in  a 
suite  with  regard  to  their  interactions  and 
interdependencies  and  reconciling  any  differences  is 
called  profiling.  Everyone  who  has  ever  designed  and 
implemented  a  system  based  on  the  combination  of 
two  or  more  standards  has  created  at  least  an  implicit 
profile,  but  the  explicit  job  of  combining  several 
standards  and  deciding  the  necessary  reconciliations 
formally  is  a  fairly  new  activity,  and  little  is  really 
known  about  how  to  do  it. 

The  PSESWG  standard  will  be  such  a  profile,  as  it  will 
cover  many  different  interface  areas  and  will  cite  many 
diverse  interface  standards.  Thus  the  issue  of  profiling 
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will  be  a  significant  one  for  the  PSE  standard.  There 
are  likely  to  be  few  obvious  problems  with  the  few 
standards  that  have  aheady  been  selected,  as  they 
cover  rather  distinct  areas.  But  even  with  these  there 
are  considerations  of  options  to  include  or  exclude  and 
parameter  ranges  to  determine.  And,  since  both 
POSIX  and  GOSIP  have  their  own  ideas  about  such 
things  as  time,  it  will  be  necessary  to  be  sure  that  these 
notions  can  be  compatibly  profiled  As  the  number  of 
standards  in  the  PSESWG  suite  grows,  addressing 
these  compatibilities  will  become  increasingly  difficult. 
It  may  well  prove  to  be  in  the  best  interest  of 
PSESWG  to  work  with  other  standards  groups  whose 
goals  are  to  create  similar  profiles  of  standards  that 
are  of  mutual  interest. 

Contentious  Interface  Areas 

There  are  a  few  interface  areas  that  were  fairly  simple 
for  the  PSESWG  to  address.  Most  of  the  rest  will  be 
much  more  diff  cult.  There  are  at  least  three  kinds  of 
problems  that  can  arise  in  trying  to  select  one 
standard  for  each  interface  area: 

1.  Sometimes  the  easiest  situation  may  be  when  there 
are  two  or  more  standards  that  clearly  cover  the  same 
services  and  functionality.  Then  a  fairly  straight¬ 
forward  evaluation  process  will  resuit  in  determining 
one  to  be  technically  and  programmatically  superior. 
This  is  most  likely  tc  happen  in  an  interface  area  ihat 
is  well-understood  and  for  which  products  have  existed 
for  some  time. 

2.  In  other  situations  there  will  be  several  choices,  but 
they  seem  to  generally  roam  all  around  the  same 
territory  without  being  dearly  comparable  or,  at  times, 
clearly  distinguishable.  Included  in  this  category  are 
those  situations  in  which  theie  is  a  great  deal  of 
diversity  and  the  marketplace  has  yet  to  establish  any 
dear  trend.  This  is  most  likely  to  happen  in  an 
bterface  area  that  is  new  but  has  quickly  become  very 
popular,  such  as  has  happened  b  the  wbdowbg  arena 
b  the  last  few  years. 

3.  In  yet  other  situations,  there  may  be  one  or  more 
choices,  but  none  of  them  seems  to  do  the  whole  job 
well.  It  is  possible  b  this  situation  to  find  that  two  or 
more  of  the  possible  choices  complement  one  another 
b  such  a  way  that  choosbg  them  both  to  support 
distinct  parts  of  the  bterface  area  would  be  sensible. 
This  is  most  likely  to  happen  b  an  bterface  area  that 
is  bebg  researched  or  slowly  explored  b  other  ways, 
but  for  which  no  consensus  answers  of  what's  right  or 
works  have  emerged. 


The  PSESWG  can  expect  to  fbd  itself  b  all  three  of 
these  situations  at  one  time  or  another  b  the  near 
future.  When  it  docs,  there  are  several  options  that 
can  be  considered: 

.  Dedde:  If  the  standards  choices  are  there 
and  the  evaluation  can  be  performed  with 
satisfactory  results,  then  raakbg  the 
s*  . lection  will  help  the  bcremental 
advancement  of  the  standard 

.  Defer  the  decision:  If  there  is  still  time  (as  is 
the  case  right  now,  for  example,  with 
choosbg  a  wbdowbg  toolkit),  it  may  be 
most  prudent  to  simply  sit  out  and  wait  a 
while  for  the  bdustry  and  the  marketplace 
to  sort  themselves  out.  A  lot  can  change  b  a 
year  or  two,  and  waitbg  is  likely  to  be 
preferable  to  selectbg  one  that  turns  out  to 
be  out  of  favor  b  a  couple  of  years. 

.  Conduct  further  analysis:  If  thbgs  seem  just 
too  confused  or  overlapping,  it  might  be  best 
to  fbd  other  ways  to  analyze  the  area  or 
other  angles  to  take  on  'he  requirements  to 
make  them  more  suitabte  to  making  a 
selection.  Perhaps  some  essential 
distbguishbg  characteristic  between  some 
of  the  available  candidates  was  missed  b  the 
development  of  the  requirements.  If  that 
element  can  be  discovered  and  bcluded  b 
the  evaluation  process,  it  may  become  more 
clear  what  choice  to  make. 

.  Stir  the  pot:  In  some  cases,  what  is  needed  is 
some  pro-active  participation  b  the 
standards  community.  If  things  are  not 
gelling  b  bdustry,  perhaps  some  attempts  to 
get  important  groups  talkbg  with  one 
another  or  listenbg  to  the 
govemmeut's/user's  needs  will  help  to  break 
the  logjam  and  get  the  necessary 
cooperation  or  attention  to  the  matter 
movbg. 

IGm" 

Despite  ail  of  the  efforts  that  can  be  made  to  address 
the  selection  of  standards  b  all  of  the  bterface  areas 
that  are  of  btsrest,  the  PSESWG  will  heritably 
encounter  some  bterface  areas  for  which  there  are 
simply  no  standards,  despite  the  apparent  PSESWG 
desires  and  requirements  for  them.  In  this  case,  some 
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hard  choices  will  have  to  be  made  between  at  least 
three  possible  alternatives: 

1.  It  should  first  be  carefully  considered  whether  or 
not  the  requirement  that  is  not  being  met  is  real.  The 
fact  that  there  is  no  standards  activity  in  the  area  may 
be  an  indication  either  that  industry  does  not  consider 
it  to  be  a  problem  or  they  are  content  with  current 
(non-standard)  solutions.  Re-examination  of  such  a 
requirement  could  result  in  the  PSESWG  dropping 
the  requirement  (or  at  least  admitting  that  reality 
suggests  being  willing  to  defer  it  significantly).  If  such 
re-examination  confirms  the  importance  of  the 
requirement,  then  other  approaches  can  be  engaged. 

2.  For  an  important  requirement  that  cannot  be 
deferred,  it  Is  possible  to  try  to  drum  up  industry 
support  and  enthusiasm  for  addressing  it.  This  is  the 
first  choice  of  the  NGCR  program,  since  the  desire  is 
to  adopt  industry  standards.  It  may  be  that  the 
PSESWG  will  have  to  put  some  resources  (e.g., 
providing  a  working  group  chair  or  doing  the 
paperwo.'k  necessary  to  get  a  new  group  or  work  item 
approved)  into  getting  something  rolling,  but  that 
would  be  far  preferable  to  the  only  remaining 
alternative. 

3.  If  by  some  chance  the  PSESWG  is  faced  with  a  truly 
urgent  requirement  for  which  no  interest  can  be  found 
in  industry,  it  may  be  left  with  no  choice  but  to 
attempt  to  provide  its  own  unilateral  interface  for  the 
area.  This  could  be  done  in  parallel  with  trying  to 
drum  up  industry  support,  so  that  the  interface 
developed  could  be  provided  to  the  new  group  as  a 
strawman  with  which  they  can  start  their  work.  This  is 
the  choice  of  absolute  last  resort,  and  it  is  not 
expected  that  PSESWG  is  likely  to  be  forced  to  this. 

£QM£LUSIQN 

The  PSESWG  is  following  the  general  tenets  of  the 
NGCR  program  in  selecting  a  set  of  PSE  interface 
standards.  An  initial  selection  of  a  few  standards  has 
been  made  and  documented.  There  is  no  direct 
PSESWG  experience  with  the  application  of  these 
standards,  although  support  environments  can  be 
found  today  that  make  use  of  products  that  conform  to 
the  selected  standards  or  others  very  similar  to  them. 

This  program  is  consistent  with  a  significant  move 
throughout  the  industry  to  open  systems  and  to  the 
use  of  industry  interface  standards.  The  expected 
benefits  include  time  and  cost  savings  and  increased 
quality,  because  usable  products  that  conform  to  the 


standards  will  be  more  readily  available,  more 
technologically  advanced,  and  more  easily  integrated 
together.  The  recommendations  from  a  report™  on 
the  Computer-Aided  Software  Engineering  (CASE) 
tool  marketplace  included  a  suggestion  that  it  was 
important  "to  gain  compatibility  among  platform 
vendors  a.  the  environment  level"  and  to  "drive 
commercial  standards  -  do  not  invent  anything  new  if 
there  is  a  commercial  alternative."  These  are  the 
objectives  of  the  PSESWG. 

The  experiences  of  the  other  NGCR  working  groups 
also  indicate  that  this  program  is  moving  in  the  right 
direction.  Two  other  standards  -  SAFENET II  (based 
largely  on  FDDI)  for  networks  and  the  backplane 
standard  (based  largely  on  FutureBus+)  -  have  been 
well  received  in  the  Navy  and  elsewhere.  Even  before 
their  final  formal  approval  they  were  being  followed 
by  Navy  projects,  indicating  a  wide-spread  interest  in 
the  anticipated  benefits  and  a  real  willingness  to  give 
this  approach  a  try. 

The  PSESWG  reference  model  has  also  been  well- 
received  so  far.  It  is  hoped  that  it  will  help  to  provide  a 
road-map  that  the  entire  PSE  industry  can  accept  and 
that  will  help  to  sort  out  the  difficulties  in  realizing 
good  integrated  environments  that  are  built  from  a 
variety  of  vendor  products. 
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ABSTRACT 

Software  systems  constructed 
during  the  past  two  decades,  and 
in  many  instances  in  the  very 
recent  past,  have  usually 
followed  the  traditional  software 
engineering  life  cycle  approach 
to  software  development: 
requirements,  specification, 
design,  code,  test,  and 
maintenance.  Software  developers 
have  usually  been  determined  to 
demonstrate  all  user 
requirements,  but  the  traditional 
life  cycle  approach  has  often 
hampered  this  desire.  Rapid 
prototyping  has  been  devised  to 
facilitate  the  process  of 
software  development.  Since  the 
first  symposium  in  1982,  a 
variety  of  rapid  prototyping 
approaches  have  been  developed. 
One  of  these  approaches  involves 
high-level  languages  designed 
especially  for  prototyping.  It 
has  also  become  increasingly 
clear  that  discrete  simulation 
can  be  used  to  good  advantage  to 
augment  the  activities  in  the 
traditional  life  cycle 
development  process.  As  software 
system  realizations  transition 
over  time,  there  is  the  need  to 
achieve  prototype  changes  easily 
and  naturally,  maintaining  a 
consistent  view  of  the  system, 
and  working  with  a  language  whose 


features  may  be  employed  in 
different  levels  of  abstraction 
with  consistency  of  syntax  and 
semantics.  This  paper  presents 
an  overview  of  the  development  of 
an  Ada-based  interface  that 
demonstrates  the  feasibility  of 
language  concepts  and  features 
that  achieve  a  joint  prototyping 
and  simulation  framework. 

Introduction 

Experience  has  revealed  that 
customers  do  not  always  nave  a 
clear  understanding  of  exactly 
what  they  really  want  their 
software  to  do.  They  know  their 
application,  but  they  cannot 
always  describe  the  details  of 
their  problems  to  outsiders. 
Even  if  care  is  taken,  the 
communication  between  a  software 
engineer  and  the  customer  can 
lead  to  misunderstandings23. 
Misunderstandings  can  result  in 

omitted  or  overlooked 
requirements,  which  will 

propagate  throughout  the  software 
development  cycle.  To  correct 
this  situation,  the  system 
requirements  will  have  to  be 
modified,  the  software 
specification  will  have  to  be 
changed  to  reflect  the  new 
requirements,  the  design 

probably  will  have  to  be 

modified,  the  code  may  have  to 
change  to  reflect  any  design 
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changes,  and  any  changed  code 
will  have  to  be  retested.  These 
setbacks  can  create  schedule 
delays.  Therefore,  good 
communication,  particularly  early 
in  the  software  life  cycle,  is 
vitally  important  to  the 
development  of  a  functionally 
appropriate  software  system. 

Sometimes  newly  discovered 
requirements  conflict  with 
previously  existing  requirements, 
thus  rendering  the  implemented 
system  useless.  Discrepancies 
between  what  customers  want  and 
what  developers  provide  may  cost 
as  much  as  100  times  more  than  if 
errors  or  omissions  had  not  been 
made  in  defining  the  requirements 
during  the  analysis  step*.  To 
facilitate  data  flow  and 
communication  during  the  early 
steps  of  the  traditional  software 
life  cycle,  additional 
development  techniques  have  been 
proposed.  Two  such  techniques 
are  discrete  simulation  and 
prototyping. 

Both  discrete  simulation  and 
prototyping  can  be  used  to  mirror 
components  of  a  "real  system" 
relative  to  time  passage, 
synchronization,  communication, 
and  the  use  of  shared  system 
resources,  while  at  the  same  time 
abstracting  away  unnecessary 
detail.  However,  they  differ  in 
their  representations  of  a 
software  system.  Discrete 
simulation  produces  more  abstract 
representations  of  a  system  than 
prototyping,  especially  with 
respect  to  time  passage. 
Discrete  simulation  models  time 
passage  using  a  simulation  clock. 
Prototyping  implements  time 
passage  using  a  real  time  clock. 
There  is  an  area  of  uncertainty 
at  the  boundary  between 
prototyping  and  discrete 


simulation,  but  the  main 
intention  of  each  is  discernable 
within  the  software  engineering 
life  cycle18.  In  order  to  provide 
a  more  complete  understanding  of 
each  technique,  brief 
descriptions  of  both  are  provide 
below. 

Discrete  Simulation 

As  digital  computers  became 
commercially  available  in  the 
1950s  and  1960s,  it  was 
recognized  that  they  possessed  a 
valuable  capability  of  evaluating 
simulation  models  as  discrete 
approximations  of  physical 
systems  being  studied.  Because 
time  in  the  physical  system  could 
be  represented  as  a  series  of 
discrete  changes,  these 
simulation  models  took  on  the 
name  "discrete  event  models", 
and  the  simulation  techniques 
used  to  computerize  these 
discrete  models  became  known  as 
"discrete  event  simulation". 
Over  the  last  three  decades, 
discrete  event  simulation 
techniques  have  become  an 
integral  part  of  some  so-called 
"high  level"  programming 
languages.  From  the  simulation 
standpoint,  these  languages  fall 
into  two  basic  categories: 
general-purpose  programming 
languages  and  special-  purpose 
simulation  languages.  The 
special-purpose  simulation 
languages  have  developed  around 
four  discrete  time  control 
strategies:  event  scheduling, 
activity  scanning,  the 
three-phrase  approach,  and 
process  interaction.  The  time 
control  strategies  are  founded 
upon  the  fundamental  concepts  of 
conditional  and  unconditional 
events.  Unconditional  events  are 
executed  by  sequencing  events 
according  to  an  agenda  that  is 
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solely  time  dependent. 
Conditional  events  are  executed 
by  sequencing  events  to  an  agenda 
that  is  not  solely  dependent  on 
time,  but  is  also  dependent  on 
other  imposed  conditions  (  such 
as,  is  the  CPU  busy?)10. 

Each  discrete  time  control 
strategy  determines  how  a  modeler 
must  view  a  system  that  is  to  be 
modeled  by  providing  alternative 
world  views.  The  term  "world 
view"  is  used  to  describe  the 
perspective  of  a  system  that  is 
assumed  when  using  a  given 
language.  Each  world  view  has 
demonstrated  itself  as  a  valuable 
simulation  approach,  and  in  many 
cases  has  led  to  the  development 
of  new  languages.  However,  the 
world  view  that  has  shown  promise 
recently  is  the  process 
interaction  approach. 

The  process  interaction 
approach  has  characteristics  of 
both  event  scheduling  and 
activity  scanning.  Any 
simulation  language  designed 
around  the  process  interaction 
approach  allows  the  user  to 
concentrate  on  a  single  entity 
(such  as  a  customer)  and  the 
sequence  of  logical  steps 
involving  the  entity1.  This 
sequence  of  steps,  or  activities, 
is  commonly  known  as  a  process. 
Each  step  of  a  process  consists 
of  a  condition  segment  and  an 
action  segment,  which  are 
characteristics  of  the  activity 
scanning  approach.  The 
successful  execution  of  the 
condition  segment  dictates 
whether  the  action  segment  is 
executed . 

The  process  interaction  time 
control  procedure  implements  two 
event  lists:  a  future  event  list 
and  a  current  event  list.  The 


future  event  list,  as  the  name 
implies,  contains  event  notices 
for  activities  scheduled  to  be 
executed  at  some  future  time. 
The  current  event  list,  as  its 
name  implies,  contains  event 
notices  for  activities  to  be 
executed  at  the  current 
simulation  clock  time,  if  their 
conditions  are  met.  Upon 
simulation  time  update,  all 
activities  scheduled  for  current 
time  are  removed  from  the  future 
event  list  and  placed  on  the 
current  event  list.  The  current 
event  list  is  scanned  to 
determine  if  the  condition 
segment  of  each  entry  can  be 
satisfied.  Those  entries  whose 
condition  segments  can  be 
satisfied,  proceed  by  executing 
the  accompanying  action  segment. 
An  activity  progresses  through  as 
many  steps  as  time  and  condition 
segments  dictate.  When  an  entity 
cannot  continue  to  advance 
through  the  sequence  of 
activities,  the  scan  of  the 
current  event  list  can  proceed 
and  the  simulation  clock  is 
advanced . 

Although  the  process 
interaction  strategy  was  accepted 
as  one  of  the  best  frameworks  for 
building  simulation  models,  it 
was  not  the  simplest  to  code. 
Nevertheless,  this  approach  was 
implemented  early  in  the  history 
of  programming  languages  via  GPSS 
in  1961. 

The  current  trends  reflect  a 
quantum  increase  in  tools  and 
methods  for  simulation,  and  all 
indications  are  that  the  momentum 
is  still  increasing.  Due  to  the 
close  conceptual  conformity  of  a 
process  interaction  model  to  its 
corresponding  system,  there  is 
every  reason  to  expect  continuing 
emphasis  on  the  process 
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interaction  world  view9. 

Rapid  Prototyping 

It  was  in  the  decade  of  the 
1900's  that  prototyping,  in 
particular  rapid  prototyping, 
received  recognition.  The  first 
symposium  on  the.  subject  was  held 
in  193225.  In  1983,  a  working 
conference  on  prototyping  was 
held  in  Germany  which  focused  on 
the  user-oriented  development  of 
information  systems.  It  was  in 
the  development  of  information 
systems  that  rapid  prototyping 
was  used  effectively.  Since  the 
occurrence  of  these  conferences, 
a  variety  of  rapid  prototyping 
approaches  have  developed.  One 
technique  is  very-high-level 
languages . 

Very-high-level  languages 
are  a  continuation  of  the 
programming  language  evolutionary 
process.  First,  there  was 
machine  language  whicn  evolved 
into  assembly  language.  Assembly 
language  evolved  into  programming 
languages,  which  provided  more 
simplicity  and  flexibility  in  the 
programming  environment. 
Programming  languages  offered 
users  the  ability  to  potentially 
code  several  assembly  language 
statements  under  the  guise  of  a 
single  programming  language 
statement.  This  provided  a  more 
readable  and  logically  shorter 
programs.  Very-high-level 
languages  take  this  concept  one 
step  further.  Semantically 
related  programming  statements 
are  gathered  together,  perhaps  in 
the  form  of  a  procedure  or 
function,  and  are  represented  by 
a  single  very-high-level 
programming  language  statement, 
thus,  further  reducing  the 
logical  size  of  a  program  and 
elevating  it  to  a  level  that 


could  be  considered  command 
driven.  Very-high-level 
languages  incorporate  software 
reusability  to  provide  users  with 
a  statement  set  that  is 
simplistic,  yet  powerful. 

The  traditional  life  cycle 
approach  did  not  accommodate  the 
evolutionary  development 
introduced  by  rapid  prototyping 
capabilities2.  However,  they  have 
been  used  within  alternative  life 
cycle  approaches,  such  as  the 
Spiral  Approach.  Very-high- 
level  languages,  have  assumed  an 
important  position  within  the 
framework  of  software  engineering 
by  offering  features  that  are 
uniform  relative  to  syntax, 
semantics,  and  "system  view". 
The  intent  of  very-high-level 
language  systems  is  to  provide 
effective  means  of  transitioning 
from  lower  to  higher  fidelity 
system  representations,  as  the 
system  realization  "hardens" 
throughout  its  development15.  Two 
successful  examples  of  very-high- 
level  language  prototyping  are 
JADE26  and  BPL11 . 

Boehm,  Gray,  and  Seewaldt* 
made  a  study  of  projects  that 
proved  to  be  well  suited  to  the 
use  of  software  prototypes. 
Their  research  revealed  that 
systems  constructed  using 
prototypes  performed  equivalently 
to.  those  systems  constructed  by 
the  more  traditional  life  cycle 
techniques.  Even  more  important, 
their  research  revealed  that 
approximately  40%  fewer  lines  of 
code  were  written  by  those  who 
used  prototypes  to  construct 
their  systems.  As  a  result, 
rapid  prototyping  has  proved  its 
usefulness  as  a  software 
development  tool  and  is  an  area 
of  increasing  importance  and 
research. 
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The  Benefits  of  a  Combination 

Rapid _ Prototvpincr/Discrete 

Sxmulation  Language  System 

As  can  be  determined  from 
the  discussion  above,  both 
discrete  simulation  and  rapid 
prototyping  have  made  a 

significant  impact  on  software 
engineering  and  each  has  been 
successfully  established  as  a 
useful  life  cycle  tool.  Discrete 
simulation  has  had  a  tremendous 
influence  on  the  development  of 
numerous  computer  programming 
languages.  Rapid  prototyping  has 
had  an  influence  by  providing  an 
alternative  development 
technique.  With  these  two  widely 
used  and  repeatedly  proven 
development  tools  available,  can 
an  advantage  be  gained  by 
combining  the  two  into  a  joint 
software  development  approach? 
If  so,  what  are  the  advantages 
and  disadvantages  of  the  joint 
development  approach?  The  answer 
to  these  questions  is  found  by 
examining  the  advantages  and 
disadvantages  of  each  tool 
individually.  Any  specific 

advantage  gained  by  a  merger  will 
be  derived  from  the  individual 
components  of  the  union. 

Therefore,  our  attention  is 
directed  to  the  specific 
advantages  and  disadvantages  of 
discrete  simulation  and  of  rapid 
prototyping. 

Advantages  and  Disadvantages  of 
Discrete  simulation 

The  concept  of  discrete 
simulation  has  been  utilized  for 
many  years  and  the  primary 

advantages  and  disadvantages  are 
well  defined.  Schmidt  and 

Taylor2*  and  Banks  and  Carson1  as 
wall  as  others  have  outlined  and 
documented  them. 


As  a  development;  tool, 
discrete  simulation  can  be  used 
early  in  the  life  of  a  software 
system.  To  assist  with  the 
analysis  of  such  a  software 
system,  a  discrete  simulation 
model  can  be  developed.  The  user 
can  repeatedly  evaluate  the 
discrete  simulation  model  with 
various  data  sets  in  order  to 
analyze  potential  designs.  If 
input  data  is  plentiful, 
different  proposed  system  designs 
can  be  evaluated  in  order  to 
determine  the  most  appropriate 
one. 

Even  when  input  data  is 
somewhat  sketchy,  discrete 
simulation  concepts  can  still  be 
used  to  aid  in  the  analysis  of  a 
proposed  system.  Actual  system 
data  is  always  preferred,  since 
it  provides  realism  to  a 
simulation;  however,  real  system 
data  is  quite  often  too  expensive 
or  perhaps  impossible  to  obtain. 
In  this  case  practicality  is  the 
rule  of  thumb.  Over  the  years  it 
has  been  shown  that  simulation 
data  is  usually  less  costly  to 
obtain  than  real  system  data. 
Simulation  data  can  be  generated 
from  a  variety  of  existing  and 
well  proven  random  number 
generators.  If  system  analysis 
can  identify  a  probability 
distribution,  then  any  necessary 
system  data  can  be  generated  from 
this  distribution  instead  of 
using  _  costly  data  gathering 
techniques. 

Generali,-  ,  when  developing  a 
software  m  >del  a  software 
engineer  can  consider  the  model 
from  two  fundamental  simulation 
approaches;  analytical  and 
numerical.  Analytical  simulation 
requires  good  insight  and 
understanding  of  the  mechanics  of 
mathematics  and  deductive 
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reasoning.  But  being  well  versed 
in  analytical  methods  may  not  be 
good  enough.  Many  systems  are  So 
large  and  complex  that 
mathematical  models  are 
impractical  to  manipulate  and 
results  are  extremely  difficult 
to  deduce.  On  the  other  hand, 
numerical  discrete  simulation 
concepts  require  computational 
procedures  which  are  executed  on 
computers  rather  than  solved 
manually.  The  executed 
procedures  produce  a  system 
history  consisting  of  data  which 
can  be  examined  to  find  expected 
results  and  to  discover 
unexpected  anomalies.  Computers 
can  also  be  used  to  efficiently 
manipulate  large  amounts  of 
system  data  used  as  inputs  or 
generated  as  outputs.  This  fact 
alone  usually  encourages  many 
more  users  of  numerical 
simulation  methods  over  the 
analytical  methods.  In  addition, 
analytical  models  usually  require 
several  simplifying  assumptions 
to  make  them  mathematically 
manageable.  Discrete  numerical 
models  do  not  have  this 
restriction.  In  many  problem 
situations  analytical  models  can 
evaluate  only  a  limited  number  of 
system  performance  measures. 
Software  engineers  implementing 
discrete  simulation  models  can 
approximate  any  conceived 
performance  measure  by  using 
generated  simulation  data. 
Therefore,  the  ensuing  cost  of 
acquiring  real  data  for  a 
proposed  system,  or  the 
difficulty  in  defining  a  suitable 
analytical  model,  often  elevates 
discrete  simulation  as  the  only 
practical  solution  to  the 
problem. 

Even  though  simulation 
during  software  development  is 
appealing  in  numerous  situations. 


there  are  also  some  side  effects 
from  the  use  of  simulation  that 
are  not  desirable.  Simulation 
models  developed  for  digital 
computers  may  be  costly  for 
several  reasons.  Large,  complex 
simulation  models  can  require  a 
good  deal  of  time  to  construct 
and  validate.  The  interactions 
that  may  take  place  within  the 
model  can  be  complicated  and 
difficult  to  define.  In  order  to 
perfect  a  model,  numerous 
computer  runs  are  required. 
However,  this  disadvantage  is 
made  tolerable  through  the  use  of 
the  special  purpose  simulation 


languages  and  constantly 
increasing  computing  capability. 

With  the  improved  special 
purpose  simulation  languages  and 
computer  facilities,  users  can 
become  very  familiar  with 
computing  techniques,  and  may 
ignore  their  mathematical 
training.  This  situation  can 
lead  to  bad  choices  for  problem 
solutions.  Sometimes  users  may 


over  look  an  obvious  mathematical 
solution  and  select  a  numerical 
solution  instead.  This  error  can 
prove  to  be  costly  in  both  time 
and  money. 


and  Disadvantages  of 


Rapid  prototyping  has  been 
in  use  by  software  developers 
only  about  half  as  long  as 
discrete  simulation.  Therefore, 
the  primary  advantages  and 
disadvantages  of  rapid 
prototyping  are  not  as  well 
documented  as  those  of  discrete 
simulation.  However,  Connell  and 
Shafer7,  and  others  provide 
insight  into  this  are3.  wa 
summarize  these  advantages  and 
disadvantages  in  the  following 
paragraphs. 
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As  a  communication  tool, 
rapid  prototyping  has 
demonstrated  itself  to  be  helpful 
and  sometimes  cost  effective  in 
many  small  and  large  projects. 
Consider  the  situation  involving 
an  incomplete  requirements 
document.  It  is  very  difficult 
to  achieve  coordination  between 
the  design  specification  and  all 
user  requirements  for  a  complex 
system  until  the  user  has 
witnessed  at  the  minimum  a 
partial  implementation.  When  a 
customer  attempts  to  relate 
requirements  to  a  system 
engineer,  uncertainty  exists 
about  what  is  needed  in  the 
software.  Users  are  busy,  they 
forget  important  details,  or  they 
really  just  aren't  interested. 
Sometimes,  not  everyone  who 
should  be  involved  in 
requirements  definition  is 
involved  and  very  important 
criteria  is  lost3.  In  this  case 
the  software  requirements  may  be 
considered  a  "wish  list",  but  not 
necessarily  a  complete  wish 
list23.  At  other  times,  the 
customer  may  have  a  basic 
understanding  of  what  is  needed 
in  the  desired  software,  but  is 
uncertain  if  it  is  feasible  to 
develop  it.  With  rapid 

prototyping,  sections  of  any 
proposed  system  can  be 
represented  and  used  to  determine 
the  feasibility  or  desirability 
of  the  customer's  perceived 
requirements.  The  requirements 
can  be  evaluated  before  the 
design  is  finalized.  Formal 
specifications  may  never  be 
documented  as  in  the  traditional 
life  cycle  approach;  however,  if 
specifications  are  desired,  the 
final  prototype  itself  may  be 
perceived  as  the  specifications 
for  the  software22. 

The  experience  and 


understanding  gained  in 
constructing  a  prototype 

transfers  into  an  overall  batter 
system.  In  terms  of  development 
cost  and  development  time,  it 
appears  to  be  more  effective  if 
changes  to  system  ambiguities 
occur  early  in  the  software 
development,  rather  than  later 
during  the  maintenance  phase 
after  the  software  has  been 
released.  Historically,  the 
functionality  of  a  system  is 
changed  by  users  late  in  the 
development  cycle  because 
software  engineers  usually  do  not 
greatly  involve  users  during  the 
pre-design  phases.  As  a  result, 
a  user's  perspective  sometimes 
turns  out  to  be  different  than 
the  design  specification  in  the 
reality  of  a  visible,  working 
system. 

However,  using  rapid 

prototyping,  the  opportunity  to 
make  functional  modifications  as 
a  result  of  changes  in  the 
requirements  can  come  at  a  much 
earlier  time.  Users  have  an 
opportunity  to  view  a  working 
model  prior  to  test  and 
maintenance.  Therefore,  an 

advantage  of  rapid  prototyping  is 
accommodating  new  or  unexpected 
customer  requirements  early  in 
the  development  cycle  rather  than 
later  during  the  test  and/or 
maintenance  stages. 

A  direct  consequence  of 
involving  the  user  early  in  the 
software  development  process  is 
the  cost  savings  that  can  occur 
in  the  maintenance  phase  of 
software  development. 
Traditionally,  using  the  software 
development  life  cycle,  most  of 
the  cost  of  software  is  not 
incurred  during  the  development 
effort  or  during  the  coding 
effort,  but  rather  during 
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software  maintenance7.  It  is  a 
fact  that  software  engineers  make 
development  mistakes  during  the 
early  phases  of  the  software  life 
cycle.  Some  of  these  errors 
surface  during  the  test  phase, 
and  others  will  go  undetected 
until  after  the  software  is 
operational.  In  the  traditional 
life  cycle  approach  a  great 
portion  of  the  development  effort 
is  directed  to  correcting 
mistakes  that  propagate  through 
the  early  phases  of  software 
development  into  software  test 
and  maintenance7.  By  using  rapid 
prototyping,  cost  reductions  in 
the  test  and  maintenance  phases 
occur  because  software 
engineering  errors  have  a  greater 
opportunity  to  be  caught  by  the 
users  before  the  test  phase 
begins.  Therefore,  fewer 
modifications  will  be  required 
after  software  delivery. 

An  additional  advantage 
gained  from  rapid  prototyping  is 
the  ability  to  discard  the 
prototype  of  an  infeasible  or 
unworkable  system  at  a  relatively 
small  loss  compared  to  the 
devastating  loss  from  discarding 
a  system  late  during  the  test  or 
maintenance  phase  of  the 
classical  software  life  cycle.  A 
software  system  that  survives  the 
inspection  of  the  user  through  a 
rapid  prototype  can  only  increase 
the  user’s  satisfaction  with  the 
final  product,  thus  providing  a 
measure  of  quality  control  and 
productivity  improvements  in  the 
development  phases  beyond  the 
analysis  prototype  design. 

One  disadvantage  with  using 
rapid  prototyping  is  not  found  in 
the  technical  approach 
implemented  by  the  users,  but 
rather  in  the  way  users  perceive 
it.  Since  rapid  prototyping  is  a 


relatively  new  technique  for 
software  development,  not  all 
software  engineers  feel 
comfortable  with  it.  Although  a 
software  system  may  be  developed 
by  using  rapid  prototyping 
techniques,  maintenance  engineers 
or  even  software  designers  may  be 
more  accustomed  to  the 
traditional  life  cycle  approach. 
A  change  in  approach  may  be 
perceived  as  criticism  of  their 
professional  ability  and  they  may 
become  uncomfortable  with  the 
situation  or  possibly  even 
hostile.  There  is  always  an 
inclination  to  reject  techniques 
that  are  not  familiar,  and  thus 
delay  their  advancement. 

In  the  same  vein  there  is  a 
shortage  of  trained  prototypers 
and  maintainers  of  prototype 
systems .  Compounding  the 
problem,  there  has  been  little 
opportunity  for  training 
prototypers  or  introducing 
developers  to  this  newer  way  of 
thinking.  Companies  that  develop 
prototyping  tools  usually  offer 
training,  but  a  general  approach 
to  rapid  prototyping  and  rapid 
prototyping  methodologies  has 
been  lacking. 

A  Merger  of  Rapid  Prototyping  and 
Discrete  Simulation 

With  rapid  prototyping  and 
discrete  simulation  working 
together  in  a  combined  language 
system,  benefits  emerge  in  all 
aspects  of  the  software  life 
cycle.  To  better  understand  how 
these  benefits  relate  to  the 
traditional  software  cycle, 
consider  the  software  life  cycle 
to  consist  or  the  following  six 
phases : 

(1)  requirements  analysis 

(2)  system  design 
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(3)  high-level  software  design 

(4)  implementation 

(5)  integration/ testing 

(6)  operation/maintenance 

In  phase  one,  during  the 
early  stages  of  the  software 
development,  it  is  very  prudent 
to  determine  the  feasibility  and 
practicality  of  individual 
requirements.  To  assist  in  this 
operation,  a  simulation  can  be 
developed  that  can  examine 
software  throughput  data  and 
determine  if  the  volume  of  data 
defined  in  a  requirement  is 
reasonable.  It  a  sufficient 
amount  of  real  data  is  not 
available  to  the  simulation, 
random  number  generators  can  be 
used  to  supply  any  amount  of  data 
necessary  to  test  these 
requirements.  It  is  also 

valuable  to  inspect  some 
potential  man/machine  interface 
requirements  at  this  point.  A 
rapid  prototype  can  be  used  to 
accomplish  this  task.  Using  a 
very  low  fidelity  representation 
of  the  software's  functionality, 
plausible  man/machine  interfaces 
can  be  constructed  and  examined 
for  their  usefulness  to  potential 
users18. 

During  phase  two,  system 
design,  assessment  capability  is 
essential  to  proper  software 
development.  Assessment  of 

resource  utilization  and  queue 
buildup  is  vital  to  the  success 
of  phase  two.  Efficient  use  of 
system  resources  and  data 
structures  is  critical  to  the 
development  of  a  usable  baseline. 
Simulation  techniques  can  be  used 
to  perform  these  assessments. 

In  phase  three,  high-level 
software  design,  proper 
assessment  can  reveal 
input/output  problems,  as  well  as 


identify  high  activity  modules 
that  require  special  attention 
from  the  developer.  In  either 
case  simulation  activities  can 
again  be  used  to  expose  software 
flaws  in  order  to  avoid  potential 
bottlenecks  during  software 
operation.  Phase  three  also 
provides  an  excellent  opportunity 
for  usage  of  prototyping 
techniques,  to  resolve  issues 
concerning  distributed  processing 
capabilities. 

After  the  software  system 
transforms  from  software  design 
into  an  implementation, 
prototyping  and  simulation  can 
still  be  valuable  tools. 
Software  engineers  can  build 
prototype  modules  to  serve  as 
drivers  and  stubs  during 
integration  ar.d  testing  (phase 
five) .  In  pha^e  six,  simulation 
and  prototyping  can  be  used  to 
evaluate  the  impact  of  changes  to 
working  software  prior  to  any 
actual  change. 

To  some  engineers  the 
concepts  of  rapid  prototyping  and 
discrete  simulation  are  very 
similar  and  may  cause  some 
confusion.  There  is  a  "gray 
area"  at  the  boundary  between 
rapid  prototyping  and  discrete 
simulation,  but  the  main  purpose 
of  each  development  approach  is 
distinguishable.  Simulation 
clearly  has  its  most  effective 
role  in  the  more  abstract 
representations  of  a  software 
system  during  requirements 
analysis,  design  assessments,  and 
maintenance.  Prototyping  has  its 
role  in  the  more  visible  aspects 
of  the  software  that  occur  during 
system  design,  software  design, 
and  integration  and  testing.  As 
the  software  transitions  through 
the  software  life  cycle,  and  the 
representations  of  system 
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characteristics  become  more 
concrete,  it  may  be  more 
appropriate  to  use  "real"  time 
instead  of  simulation  time.  This 
change,  implies  a  natural  flow 
from  simulation  to  prototyping 
crossing  each  phase,  yet 
maintaining  a  consistent  view  of 
the  software  system  under 
development.  By  using  a  joint 
simulation/prototyping  language 
system,  this  time  flow  capability 
can  be  achieved17,18. 

NICLS 

To  demonstrate  the  validit  * 
of  a  combined  language  system 
supporting  discrete  simulation 
within  a  rapid  prototyping 
environment,  a  study  has  been 
conducted  with  emphasis  on 
developing  an  interface  to 
discrete  simulation  languages  and 
rapid  prototyping  languages.  The 
interface  was  named  NICLS 
(Natural  Interface  for  a  Combined 
Language  System)  and  is 
pronounced  "Nichlas" .  The 
purpose  of  the  study  is  fourfold: 

(1)  to  select  a  discrete 
simulation  language,  which 
possesses  a  set  of  language 
statements  that  will  serve  as  a 
representative  of  the  discrete 
simulation  languages, 

(2)  to  select  a  rapid 
prototyping  language,  which 
possesses  a  set  of  language 
statements  that  will  serve  as  a 
representative  of  the  rapid 
prototyping  languages, 

(3)  to  utilize  the  programming 
language  features  of  the  discrete 
simulation  representative  and  the 
rapid  prototyping  representative 
by  means  of  an  interface  from  a 
general  purpose  programming 
language. 


(4)  to  select  a  general  purpose 
programing  language  to  serve  as 
a  base  language  as  well  as  a 
medium  in  which  the  interface  can 
be  developed. 

The  results  of  the  study  yielded 
the  selection  of  Ada  as  the 
general  purpose  programming 
language,  the  Behavior- 
Prototyping  Language  (BPL) 11,12  as 
the  representative  of  rapid 
prototyping  languages,  and 
Simulation  and  Modelling  on  Ada 
(SAMOA)21  as  the  representative  of 
discrete  simulation  languages. 
The  basis  for  each  of  these 
selections  is  outlined  below. 

Ada  as  a  General  Purpose 
Programming  Language 

Although  relatively  new  as  a 
general  purpose  programming 
language,  Ada  has  obtained  a 
respected  following  within  the 
software  engineering  community. 
It  was  developed  under  the 
leadership  of  the  United  States 
Department  of  Defense  to  be  used 
initially  within  large,  real  time 
embedded  computer  systems.  Ada 
proved  to  be  adaptable  across  a 
diversified  set  of  applications 
in  both  the  commercial  and  the 
government  communities.  Ada's 
success  was  due  to  i  its 
suitability  across  the  software 
life  cycle.  It  possesses 
features  designed  to  facilitate 
both  classical  software 
engineering  and  rapid 
prototyping8.  Some  of  ^hese 
features  are  the  more  modern 
software  engineering  principles: 
data  abstraction,  information 
hiding,  modularity,  concurrency, 
portability,  strong  typing, I  and 
versatile  syntax.  These 
principles  allow  Ada  to  bridge 
the  gap  between  past  programming 
languages  and  current  software 
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development  methodologies. 

BEL 

BPL  was  selected  as  the 
representative  of  the  rapid 
prototyping  languages  based  on 
the  following  criteria:  language 
features,  proven  application,  and 
availability  of  information.  BPL 
offered  an  excellent  example  of  a 
very-high-level  rapid  prototyping 
language,  and  it  provided  stable 
guidance  in  the  development  of 
the  rapid  prototyping  features. 

BPL  was  designed  to  provide 
language  features  uniform 
relative  to  syntkx,  semantics  and 
system  view.  It  was  purposely 
designed  to  j  achieve  rapid 
prototyping  of  system  behavior  by 
use  of  abstraction,  which  can  be 
performed  to  different  levels 
with  good  effect].  The  syntax  and 
semantics  of  ]  BPL  language 
statements  were  influenced  by 
several  existing  languages,  the 
most  influential  being  SETL1’, 
Simscript20,  and!  Pascal.  BPL  is 
not  a  "strong  data  typing" 
language  due  to  ithe  influence  of 
set-theoretical  i  concepts  from 
SETL.  Rather  BPL  is  a  strong 
object-typing  language. 

BPL  was  designed  by  Dr. 
James  W.  Hooper.  It  was  based  on 
research  performed  at  the 
University  of  Alabama  in 
Huntsville.  It  was  developed  for 
the  United  States  Army  Ballistic 
Missile  Defense  (BMD)  Advanced 
Technology  Center  for  use  on 
their  Distributed  Data  Processing 
Testbed.  Dr.  Hooper  is  serving 
as  advisor  to  the  NICLS  research 
effort  and  is  available  to 
provide  first-hand  information 
concerning  the  implementation  of 
BPL. 


SAMOA  was  selected  as  the 
representative  for  the  discrete 
simulation  languages  based  on  twc 
criteria:  case  language  and 
simulation  world  view. 

SAMOA,  as  the  name  implies, 
has  Ada  as  the  base  language  and 
was  an  attempt  by  its  developers 
to  apply  Ada  constructs  toward 
the  development  of  a  fully 
integrated,  discrete  event 
simulation  language.  The  design 
of  SAMOA  was  guided  by  two  goals: 

(1)  limiting  the  number  of  Ada 
programming  statements  a  user 
must  knew  to  a  Pascal  equivalent 
subset.  This  could  potentially 
ease  the  transition  of  non-Ada 
programmers  to  an  Ada-based 
language ,  and 

(2)  allowing  users..  when 
necessary,  to  have  access  to  the 
full  power  of  Ada.  This  provides 
the  knowledgeable  Ada  programmer 
a  full  arsenal  of  Ada  language 
capabilities  to  apply  to  the 
problem  at  hand. 

By  possessing  a  Pascal  like 
subset,  SAMOA  provides  a  rich 
supply  of  known  programming 
features  to  integrate  with  the 
BPL  programming  features. 

SAMOA  approaches  discrete 
simulation  from  the  process 
interaction  world  view,  and 
demonstrates  a  continued  trend  of 
increased  usage  of  this  world 
view  in  discrete  simulation 
languages  within  the  United 
States. 

The  Guiding  Principles  in  the 
Development  of  NICLS 

The  guiding  principles  used 
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during  the  development  of  NICLS 
follow  the  principles  outlined  in 
Hooper13.  Those  principles  are: 
understandable  language  concepts, 
understandable  language  syntax, 
computational/representational 
power  and  flexibility,  and 
support  for  the  software 
development  process.  Although 
the  principles  discussed  by 
Hooper  were  simulation  oriented, 
their  applicability  to  NICLS  is 
just  as  valid. 

The  Overall  Aporoa ch  to  NICLS 

NICLS  provides  a  syntactic/ 
semantic  approach  to  software 
development.  All  NICLS 
statements  are  syntactically 
identical  whether  they  appear  in 
a  simulation  or  in  a  rapid 
prototype.  However,  their 
interpretation  depends  on  the 
semantics  of  the  module  that 
contains  them.  A  preprocessor  is 
used  to  translate  the  NICLS 
statements  into  standard  Ada. 

A  program  may  contain  a 
combination  of  NICLS  and  Ada 
statements.  The  preprocessor 
scans  for  the  NICLS  statements 
while  ignoring  the  accompanying 
Ada  statements.  It  recognizes 
the  NICLS  statements  because  they 
have  an  augmented  Ada-like  syntax 
that  is  distinguishable  from 
standard  Ada  by  the  preprocesor. 
Once  the  preprocessor  has 
completed  the  translation 
process,  the  Ada  compiler 
provides  the  run-  time  support. 

The  Combined  Language  Features  of 
NICLS 

Within  any  software 
development  effort  there  exist 
aspects  that  can  be  considered 
the  principal  aspects  of  the 
system.  In  many  instances  these 


aspects  can  be  defined  using 
abstract  representations. 
However,  unless  there  exists  some 
set  of  implementable  mechanisms 
corresponding  to  the  abstract 
representations,  these 
abstractions  will  ba  useless.  In 
order  for  NICLS  to  be  a  viable 
software  development  tool,  it 
must  demonstrata  a  useful  set  of 
implementable  mechanisms.  Thus 
there  remained  the  task  of 
identifying  for  NICLS  these 
implementable  mechanisms. 

Some  of  the  mechanisms  can 
be  easily  identified.  For 
example,  consider  "Time  Passage" 
as  the  candidate  for  abscract 
representation.  Time  passage 
from  a  software  developer's 
perspective  can  be  envisioned  as 
two  distinct  clocking  mechanisms, 
simulation  time  and  real  time. 
If  simulation  time  is  selected  as 
the  desired  clock  strategy,  then 
the  corresponding  mechanism  can 
be  a  transformation  module  that 
operates  in  a  simulation 
framework  (i.e.,  a  simulation 
clock  and  a  future  event  list) . 
If  real  time  is  chosen  as  the 
desired  clock  strategy,  then  the 
corresponding  mechanism  is  a 
transformation  module  that 
operates  in  a  prototyping 
framework  (i.e.,  real  time 
delays) . 

By  using  the  time  based 
transformation  modules  described 
above,  an  added  bonus  is 
revealed.  If  the  transformation 
modules  are  implemented  so  that 
the  programming  statements 
composing  them  are  identical 
syntactically,  and  the  only 
difference  between  the  simulation 
transformation  module  and  the 
prototyping  transformation  module 
is  the  interpretation  applied  to 
the  programming  statements,  then 
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a  key  programming  element  that  is 
necessary  for  a  clean  transition 
from  low  fidelity  to  high 
fidelity  is  manifested.  This  key 
programming  element  is 
consistency.  Consistency  occurs 
because  the  transformation 
modules  look  the  same  from  a 
programming  perspective,  but  the 
interpretation  is  dependent  upon 
the  semantics  implied  by  the 
implementation.  This  establishes 
a  working  framework  that  can 
evolve  semantically  from  a 
simulation  framework  to  a 
prototyping  framework. 

To  properly  use  this  key 
programming  element  to  its  full 
potential  requires  that  the 
programming  framework  contain 
transitional  statements  that 
appear  syntactically  identical, 
yet  are  translated  according  to 
the  semantics  implied  by  the 
framework  containing  them.  An 
example  of  such  a  transitional 
statement  is  the  DELAY  N 
statement.  In  a  simulation 
framework  DELAY  N  causes  some 
event  within  the  simulation  to  be 
placed  on  the  future  event  list. 
When  the  simulation  clock  is 
updated  by  N  time  units,  the 
event  is  removed  from  the  future 
event  list  and  reactivated. 
Alternatively,  DELAY  N  in  a  real 
time  framework  causes  some  event 
to  become  idle  until  N  real  clock 
units  have  elapsed,  then  the 
event  is  reactivated.  Notice 
that  the  statement,  DELAY  N,  has 
the  same  syntax  for  both 
implementations,  but  the 
interpretation  is  dependent  upon 
the  semantics  of  the  enclosing 
framework. 

In  order  for  programming 
statements  like  DELAY  N  to  have 
meaning  as  trar,  sitional 
statements  within  NICLS,  they 


must  be  viable  programming 
statements  in  both  simulation 
languages  and  prototyping 
languages.  This  concept  is 
currently  directing  the 
investigation  leading  to  the 
definition  of  a  set  of 
transitional  statements.  A 
comparison  for  syntactic 
uniformity  is  being  made  using 
programming  statements  from  both 
SAMOA  and  BPL.  It  is  our  goal  to 
complete  this  study  and  have  a 
working  version  of  NICLS  by  che 
end  of  this  year. 
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Abstract 

Ada  was  designed  for  programming  in  the  small  as  well  as  for  programming  in  the  large.  As  far  as  programming 
in  the  large  is  concerned,  its  main  features  are: 

-  packages  for  modularity, 

-  tasks  for  concurrency, 

-  and  exceptions  for  reliability. 

Currently,  these  features  arc  well  supported  for  centralized  environments,  however  they  raise  some  problems  in 
distributed  environments.  Several  ways  of  addressing  the  issue  have  been  considered:  for  instance,  in  Ada  9X  new 
programming  language  constructs,  e.g.  virtual  nodes,  are  proposed;  we  investigate  an  alternative  approach  which 
consists  of  a  software  tool  for  transforming  standard  Ada  programs  into  distributed  Ada  programs. 
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l.  Introduction 


The  importance  of  distributed  systems  has 
undergone  constant  growth  ovc;  the  past  decade.  This 
trend  is  due  to  a  number  of  factors  including: 

-  the  decreasing  cost  of  processors, 

•  the  continuously  increasing  power  of 
these  processors, 

-  the  high  capacities  and  speeds  achieved 
by  computer  networks. 

On  the  other  hand,  the  complexity  and  the  cost 
of  applications  running  on  these  powerful  systems 
have  taken  on  considerable  proportions^.  The  main 
reason  lies  in  the  fact  that  it  is  often  difficult  to  use 
software  design  concepts  and  tools  which  are  mostly 
intended  for  non-distributed  programming.  High  level 
languages  very  rarely  include  abstractions  which  make 
distribution  easy  to  handle.  As  a  result,  information 
characterizing  the  hardware  configuration  of  the 
network  is  directly  embedded  in  the  application  code. 
Structures  of  this  kind  are  a  serious  obstacle  to  tne 
portability  and  maintainability  of  the  application. 

It  is  also  true  that  programmers  may  not  feel 
that  the  task  of  distributing  their  applications  actually 
concerns  them.  The  use  of  several  processors  is  a 
simple  way  of  accelerating  the  execution  speed  of  their 
programs,  in  this  case,  the  description  of  distribution 
functions  by  the  programmer  becomes  a  painstaking 
task.  The  problem  is  now  one  of  implementation  and 
optimization  of  the  application. 

Ada  is  currently  one  of  the  few  languages 
possessing  a  fully  integrated  parallelism  model. 
However,  version  Ada83  incorporates  no  specific 
distribution  features.  More  particularly,  the  language 
does  not  define  the  unit  of  distribution  (task,  package, 
etc.)  and  contains  no  abstraction  suited  to  the  problem 
(processor  assignement  for  tasks,  inter-process 
communication  and  synchronization,  etc). 


(programmed  mode)  or  dynamically  (interactive  or 
automatic  mode); 

-  Inter-node  communication  is  entirely 
handled  by  the  system  and  remains  transparent  to  the 
programmer. 

The  STRAda  system  consists  in  translating  one 
Ada  program  into  another  Ada  program.  In  the 
transformed  program,  tasks  are  replaced  by  distribution 
units  and  inter-task  communications  become  inter-node 
communication.  The  system  provides  of  a  user 
interface  used  to  place,  monitor  and  control  tasks  in 
operational  mode. 


In  part  one  of  this  article  the  authors  classify 
projects  dealing  with  the  Ada  distribution  issue.  Parts 
two  and  three  specify  and  substantiate  the  choices 
adopted  in  the  STRAda  project.  Implementation  is 
dealt  with  in  part  four.  The  last  section  provides  an 
evaluation  of  completed  work. 


2.  Current  approaches  of  addressing 


the  issue 


Although  the  Ada  language  has  not  excluded  the 
distributed  aspect  of  applications  ,  it  dobs  not  include 
the  basic  concepts  necessary  to  a  simple  expression  of 
this  distribution,  as  is  the  case  for  parallelism  and 
other  advanced  software  engineering  concepts.  A 
number  of  investigations  have  been  brought  to  bear  on 
this  aspect  of  programming  which  address  the  issue 
from  various  different  angles.  A  classification  system 
developed  by  Bishop  and  Hasling  ®  sjims  up  these 
methods; 


involved? 


1  -  How  many  Ada  programs  are 


Either  a  single  Ada  program  is 
partitioned  for  distribution  over  the  network  or  several 
Ada  programs  are  run  locally  at  each  node  and 
communicate  with  each  other  across  an  independent 
message  system. 


The  STRAda  system  ( Systime  de 
Transformation  el  de  Repartition  Ada  or  Ada 
transformation  and  distribution  system)  completes  Ada 
and  provides  a  simple  way  of  solving  the  distribution 
issue.  It  is  based  on  the  following  principles: 

-  The  task,  which  is  the  unit  of 
parallelism  in  Ada,  is  chosen  as  the  distribution  unit  of 
the  application; 

-  Processor  assignement  for  tasks  at  the 
various  network  nodes  is  performed  either  statically 


2  -  How  is  communication  among  nodes 

expressed? 

Communication  can  be  explicitly 
expressed  by  the  programmer  of  the  application,  or  it 
can  be  implicit  and  transparent  to  the  programmer 
when  generated  by  the  translator  or  tool  dedicated  to 
this  service. 

3  -  What  is  the  degree  of  liberty  left  to 
the  programmer  as  far  as  the  unit  of  distribution  is 
concerned? 
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A  number  of  language  constructs 
could  be  considered  to  comply  with  the  profile  of  a 
distribution  unit,  the  most  important  being  packages 
and  tasks,  although  subroutines  and  even  variables 
could  also  be  distributed. 

4  -  How  is  the  distribution  map 

specified? 

Distribution  of  units  to  the  various 
nodes  can  be  explicitly  described,  using  a  dedicated 
langrage  for  instance,  or  automatically  by  a  dynamic 
graphical  analysis  of  the  network  used. 

The  authors  define  several  ways  of  addressing 
the  problem  according  to  the  choices  made  with  respect 
to  these  criteria.  The  disadvantage  of  the  most 
fundamental  approach  (several  Ada  programs)^  may 
be  that  checking  among  programs  running  on  several 
nodes  could  fail.  However,  this  pitfall  could  be  avoided 
by  using  dedicated  communication  packages. 

|  The  next  two  classes  involve  single  Ada 
programs  and  imply  constraints  on  distribution  units. 
Communication  can  either  be  explicit  ,4>  1  or  implicit 
27,  2,  10. 

The  !a-  class  explored  involves  Ada 
applications  ir  mich  no  constraints  are  made  on 
distribution  mils.  The  most  advanced  project  in  this 
area  is  the  APPL  project  *5, 13. 


while  a  lower  level  abstraction  specifies  how  each 
action  is  to  be  completed 

The  underlying  principle  of  data  dissimulation 
consists  in  rendering  inaccessible  certain  details  which 
must  not  affect  other  parts  of  the  system.  In  STRAda, 
for  instance,  the  protocol  used  on  the  network  is 
hidden:  authorizing  it  would  constitute  a  breach  of 
distribution  abstraction  logic. 

Ada  is  one  of  the  rare  widely  used  languages  to 
incorporate  a  parallelism  model.  The  Ada  task  is  an 
abstract  model  of  parallelism  and  is  independent  of  the 
host  system.  The  rendezvous  concept  lets  tasks 
synchronize  and  communicate.  This  property  is 
essential  in  designing  portable  parallel  applications. 

On  the  other  hand  however,  Ada  does  not 
provide  an  abstraction  which  can  be  used  to  express 
distribution.  In  the  case  of  distributed  applications,  the 
programmer  must  therefore  use  the  distribution  model 
provided  by  the  host  system.  In  UNIX  systems  for 
instance,  the  distribution  model  is  defined  by  the 
process  as  a  distribution  unit  and  sockets  the  means  of 
communication  between  processes. 

Consequently,  the  portability  of  such 
applications  is  badly  compromised  by  the  fact  that 
implementation  details  which  are  too  close  to  the 
hardware  used  are  taken  into  account. 


!  The  STRAda  system  used  the  Ada  parallelism 

jj.  STRAda  and  Softwnre  Engineering  model  as  the  basis  of  the  distribution  model.  Indeed, 

parallelism  and  distribution  have  many  points  in 
common.  Using  the  same  unit  for  both  parallelism  and 
The  STRAda  system  consists  in  transforming  a  distribution  is  therefore  natural,  the  same  being  true  for 

classic  Ada  program  into  another  equivalent  program.  communication  and  synchronization  mechanisms.  This 

The  essential  aim  of  the  transformation  operation  is  to  association  enables  the  STRAda  system  to  render 

take  into  account  the  existence  of  several  processing  distribution  totally  transparent  to  the  programmer.  It 

nodes  in  order  to  globally  increase  the  performance  of  can  ^  sa*d  tha*  Para^c^sm  *n  Ac*a  *s  a  programming 

the  application.  The  extensions  fully  comply  with  ihe  concept  which  is  available  to  the  programmer  and  that 

initial  semantics  of  the  language  and  are  based  on  the  distribution  with  STRAda  is  a  programming  concept 

most  fundamental  software  engineering  principles.  which  is  hidden  from  the  programmer. 

3.1.  Portability  3-2-  as.Li.3fr.il.tty 


Portability  is  the  ease  with  which  a  software 
product  can  be  adapted  to  different  hardware  and 
software  environments  22,  Portability  is  improved  by 
applying  software  ergineering  principles  such  as 
abstraction  and  data  dissimulation. 

The  basic  principle  of  abstraction  consists  in 
extracting  the  vital  property  of  one  level  while 
omitting  details  that  are  not  crucial  24.  a  high  level 
abstraction  specifies  which  actions  must  be  performed 


Reliability  is  the  ability  of  software  to  operate 
even  under  adverse  conditions  22. 

One  of  the  most  fundamental  requirements  of 
embeded  systems,  for  which  Ada  was  specifically 
designed,  is  reliability.  This  means  that  no  errors  are 
allowed  to  remain  in  the  system.  Residual  errors  are 
nevertheless  inevitable  such  as  erroneous  input  data, 
for  example.  When  exceptions  of  this  sort  occur,  such 
as  a  divide  by  zero,  most  languages  stop  processing 
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and  the  operating  system  takes  over  this  should  not  be 
true  of  a  reliable  real-time  system. 

Ada  exceptions  allow  detecting  abnormal 
situations  and  processing  them  with  specific  action. 
Detection  of  abnormal  situations  is  ensured  by  the 
hardware,  system  software  or  the  user  application.  Any 
exceptions  detected  must  compulsorily  be  processed. 

In  distributed  Ada  applications,  the  exception 
concept  cannot  be  applied  to  the  whole  application.  In 
effect,  either  the  application  consists  of  several 
independent  applications,  in  which  case  exceptions 
vary  from  node  to  node,  or  the  application  is  a  single 
program,  in  which  case  inter-node  communication 
generally  does  not  cater  for  exception  transmission. 
This  type  of  situation  occurs  when  exceptions  take 
place  during  a  rendezvous  between  two  tasks  located  on 
different  nodes. 

3.3.  Rfi-USaiLllLjU 

Reusability  is  the  ability  of  software  to  be 
totally  or  partially  reused  for  new  applications  Many 
software  components  are  similar:  it  would  be 
interesting  to  exploit  these  similarities  to  avoid 
performing  redundant  work.  In  distributed  applications, 
there  is  often  a  need  for  a  program  wnich  already  exists 
for  a  different  hardware  configuration  (different  number 
of  processors,  different  processor  types,  etc.) 

Reusability  directly  affects  all  other  cost  and 
quality  factors.  When  all  or  part  of  an  existing  software 
program  is  reused,  development  costs  are  diminished  in 
all  the  phases  of  the  software  life  cycle.  Software 
components  already  tested  on  other  target  systems  are 
used,  which  increases  the  reliability  of  the  application. 

Ada  provides  a  high  degree  of  reusability  thanks 
to  features  such  as  genericity:  i.e.  the  ability  to 
parametrize  a  library  unit.  Parametrization  increases  the 
reuse  potential  of  these  units. 

Since  no  distribution  units  exist  in  Ada,  data 
relating  to  the  hardware  configuration  the  application  is 
actually  going  to  run  on  are  disseminated  throughout 
the  program.  Reuse  of  the  program  for  another 
configuration  (also  called  reconfiguration)  is  not  a 
simple  task  since  all  levels  of  the  distributed 
application  must  be  reworked. 

With  STRAda  on  the  other  hand,  all 
information  concerning  the  hardware  configuration  are 
supplied  during  another  phase  which  is  totally 
separated  from  the  application  logic  programming 
stage.  Reconfiguration  only  involves  modifying  this 


phase  dedicated  to  configuration:  the  Ada  program 
pertaining  to  application  logic  is  not  modified. 

3.4.  Qitiej _ gJlgrgc.tgrigtjS? 

Efficiency  means  making  good  use  of  available 
hardware  resources  22,  jt  has  often  been  thought  that 
the  efficiency  of  an  application  diminishes  when  the 
level  of  the  language  used  to  program  it  increases.  The 
contrary  has  been  proved  with  applications  written  in 
Ada  and  rewritten  in  assembly  language.  Indeed,  the 
executable  originating  from  Ada  is  sometimes 
extremely  efficient.  This  can  be  explained  by  the  fact 
that  the  compiler  uses  several  optimizing  techniques 
that  assembly  programmers  do  not  use. 

In  the  same  way,  optimizing  techniques  can  be 
implemented  (processor  assignement  to  balance  out 
loads,  use  of  the  right  protocol,  etc)  in  the  STRAda 
system  which  can  make  applications  using  this  system 
more  efficient. 

Ease  of  use  refers  to  the  ease  with  which  the 
users  of  a  software  program  leam  to  operate  it  22.  u  is 
obvious  that  the  higher  the  abstraction  level,  the 
greater  the  ease  of  use.  As  STRAda  possesses  a  higher 
level  of  abstraction  for  distribution  than  distributed 
programs  written  in  Ada83,  it  is  easier  to  use. 

4.  STRAda  and  the  SQtutiaiKL.ad<mled 


In  the  previous  sections  we  have  discussed  the 
importance  of  a  high  level  abstraction  model  for 
distribution.  In  the  SIT  Ada  project,  we  have  reused 
the  Ada  task  model  for  distribution.  This  choice  is  in 
line  with  the  target  architecture:  a  network  of 
workstations.  A  finer  decree  of  distribution,  such  as 
that  adopted  by  APPL1^  seems  to  us  to  be  better 
suited  to  a  massively  parallel  architecture  (example  :  a 
transputer  network). 

The  choice  of  using  Ada  tasks  as  the 
distribution  units  and  the  desire  to  maintain  Ada 
concepts  such  as  exceptions  for  the  distributed  program 
lead  us  to  adopt  the  single  program  model  for  the 
distributed  application. 

The  basic  principle  of  the  project  consists  in 
developing  a  minimal  distribution  kernel  used  to 
implement  all  the  more  specific  concepts  of  the  Ada 
language.  For  the  minimal  kernel,  we  have  opted  for 
communication  via  message  exchange.  A  certain 
number  of  aspects  of  the  language  are  not  accounted  for 
by  the  distribution  kernel  such  as  shared  variables  and 
task  termination.  In  section  5  we  shail  discuss 
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implementation  of  these  points  in  terms  of  services 
■provided  by  the  minimal  kernel. 

Implementation  consists  in  translating  an  Ada 
source  program  into  another  Ada  program  (figure  IV  In 
the  transformed  program,  all  constructs  relating  to 
parallelism  and  communication  are  replaced  by  calls  to 
services  provided  by  the  STRAda  kernel. 

To  conclude,  some  of  the  most  interesting 
facets  of  STRAda  include  a  minimal  kernel  adapted  to 
the  Ada  language  and  reuse  of  existing  systems 
without  any  modification  (Ada  compilers,  UNIX 
operating  system  etc.). 


Figure  I:  The  STRAda  kernel 


5.  Defining  a  distributed  kernel 

adapted  to  Ada 


In  thid  section,  we  shall  lock  at  the 
relationships  we  have  identified  between  the  concepts 
and  mechanisms  of  the  Ada  programming  language  and 
the  UNIX  operating  system.  We  shall  do  this  by 
examining  parallelism,  synchronization  and 
distribution  issues. 

5.1.  Parallelism 

We  have  quite  naturally  associated  a  UNIX 
process  with  each  Ada  task.  However,  from  a  purely 
practical  point  of  view,  this  may  seem  costly:  we 


could  have  considered  using  the  technique  found  . 
most  compilers  of  multiplexing  several  tasks  with  .1  a 
single  UNIX  process  (pseudo-parallelism). 
Nevertheless,  the  implementation  strategy  adopted  has 
the  following  advantages: 

-  real  parallelism  within  an  Ada  program 
is  made  possible  on  multi-processor  UNIX  stations; 

-  the  underlying  operating  system 
(UNIX)  can  be  reused  more  efficiently,  as  the 
synchronization  of  an  Ada  task  is  expressed  directly  in 
terms  of  the  synchronization  of  the  support  process. 

In  the  STRAda  system,  parallelism  and 
distribution  are  implemented  by  remote  task  creation. 
The  site  where  the  task  is  resident  is  currently  specified 
explicitly  when  the  task  is  created. 

5.2.  Synchronization  and  communication 

In  order  to  install  the  distributed  version  of 
Ada's  synchronization  and  communication  instructions, 
we  have  chosen  sockets  to  support  synchronization  and 
communication.  Each  Ada  entry  is  associated  with  a 
socket  and  a  port.  The  UNIX  primitives  ( sendto , 
recvfrom,  select)  make  it  possible  to  send  or  receive  on 
one  of  these  entries  or  tc  select  an  entry  from  a  set  of 
entries. 

Currently,  each  Ada  task  handles  its  own  rendez¬ 
vous;  we  could  have  designed  a  more  efficient  strategy 
with  each  site  having  a  single  rendez-vous  server. 

The  solution  adopted  has  certain  limitations, 
but  it  also  has  the  considerable  advantage  of  enabling 
direct  reuse  of  the  UNIX  communication  system. 

5.3.  Exceptions 

We  have  seen  that  developing  a  distributed 
application  with  STRAda  frees  programmers  from  the 
need  to  plan  for  distribution.  This  rule  still  applies 
where  an  exception  is  raised  at  a  site  and  has  to  be 
handled  on  another  site. 

In  a  non-distributed  application,  the  Ada  run 
time  system  handles  the  propagation  of  the  exception 
and  locates  the  corresponding  exception  handler.  In  a 
distributed  application  with  STRAda,  the  STRAda 
kernel  handles  the  propagation  of  the  exception 
between  two  remote  sites  where  necessary.  As  the 
distribution  unit  is  the  task,  such  propagation  is 
required  in  the  following  cases: 

-  when  an  exception  is  raised  during  a 

rendez-vous; 
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-  when  attempting  to  rendez-vous  with 
an  aborted  task; 

when  an  exception  is  raised  as  a  task 

is  being  created. 

It  is  useful  to  be  able  to  handle  exceptional 
circumstances  that  can  arise  in  distributed  systems 
(such  as  communication  or  processor  failures)  by  using 
exceptions.  The  STRAda  kernel  must  therefore  be 
capable  of  raising  such  exceptions  and  propagating 
them  to  the  destination  tasks. 

An  exception  that  has  to  be  propagated  from 
one  distributed  task  to  another  must  be  intercepted  and 
sent  to  the  remote  program  in  coded  form.  When  the 
program  receives  it,  it  is  then  decoded  and  the  original 
exception  is  explicitly  raised  in  the  destination  task. 
The  Ada  kernel  then  takes  over  on  site. 


Transformed 

Ada 

Application 


STRADA  TASKS 


STRAda 

kernel 


|  Packages 

J  Creation-Server 

»  »  i 

Host 

System 


Messages 
sent  to 
other  nodes 


UNIX 

- £ - 

Synchronisation  and 

communication 
messages  received 
from  other  nodes 


- A - 1 

Creation  requests 
received  from 
others  nodes 


5.4.  Architecture  and  ?r.^lemen^ation 

of  the  jSIBAriaJssmsl 

The  STRAda  kernel  consists  of; 

-  a  package  providing  tasks  with 
services  for  parallelism,  communication  and 
synchronization; 

-  a  set  of  tasks,  called  Server-Creation, 
each  executing  at  each  application  site  (see  figure 
between:  STRAda  Architecture). 


An  application  task  synchronizes  itself  or 
communicates  by  using  Ada's  dedicated  instructions 
(i.e.  task  declaration  or  dynamic  task  creation,  entry 
call  or  acceptance  of  a  rendez-vous  on  an  entry,  select, 
etc.).  These  subroutines  use  sockets  to  communicate 
directly  with  a  remote  task,  or  with  a  Server-Creation 
task.  Each  Server-Creation  task  initializes  tasks  to  be 
executed  at  the  site.  It  does  this  by  creating  a  UNIX 
process  and  assigning  it  a  unique  name.  In  this  way,  to 
create  a  task  on  a  site  S,  the  parent  task  communicates 
via  the  STRAda  package  with  the  site's  Server- 
Creation  task,  which  then  returns  the  data  that  the 
parent  task  needs  to  synchronize  or  communicate 
directly  with  the  task  created  (entry  points  represented 
by  UNIX  sockets).  The  table  below  shows  the  contents 
of  the  package  in  summary  form. 


STRAda  primitives 

Function  performed 

CREATE 

Create  task 

CALL 

Call  task  entry 

ACCEPTT 

Accept  rendez-vous  without  exchange  of  data  (caller  riot  b'oeked) 

ACCEPT_DO 

Accept  rendez-vous  with  exchange  of  data  (caller  blocked  until  end  of 
rendez-vous) 

SELECTT 

Accept  one  of  several  lez-vous,  immediate  or  deferred 
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6.  Transforming  the  Ada  model  into  a 
UNIX  mode! 


In  this  section,  we  shall  take  a  brief  look  at 
how  the  transformations  proposed  are  implemented. 
We  start  off  with  an  overview  of  the  too!  we  used,  we 
Cornell  Synthesiser  Generator  26  (for  more  details  and 
examples,  refer  to  25).  We  then  go  on  to  discuss  the 
transformation  principles  and  choices  adopted. 

6.1.  The  Cornell  3ynthesim_G£ng.r.a.toi 

The  Cornell  Synthesizer  Generator  (CSG)  is  a 
tool  that  uses  an  assigned  abstract  syntax  to  generate  a 
syntax  editor.  The  programming  language  used  by  the 
CSG  is  the  Synthesizer  Specification  Language  (SSL). 

In  SSL,  abstract  trees  are  specified  using  the  concept  of 
a  phylum.  A  phylum  is  a  type  of  tree  with  nodes  that 
are  constructed  recursively  using  specific  operators  and 
phyla.  For  the  STRAda  project,  we  chose  the  abstract 
syntax  DIANA  *2  (Descriptive  Intermediate  Attributed 
Notation  for  Ada).  The  main  reason  for  this  is  that 
DIANA  is  considered  to  be  the  standard  notation  for 
Ada  programs,  so  STRAd?  will  be  able  to  integrate 
with  other  tools  like  Anna  Another  important 
feature  of  the  CSG  is  that  the  abstract  trees  may 
contain  synthesized  or  inherited  attributes  1 1 .  These 
attributes  ate  normally  used  to  express  the  language's 
semantic  checks.  We  have  used  them  in  the  STRAda 
project  to  synthesize  other  programs. 

6.2.  Transformation _ Brin&i&ies 

Here,  we  shall  look  at  the  transformation 
principles  used  in  an  Ada  program.  We  should  recall 
that  the  aim  of  transformations  is  to  replace  all  Ada 
instructions  concerning  parallelism  and 
synchronization  with  equivalent  instructions  calling 
the  STRAda  kernel  we  have  already  described.  We 
concentrated  mainly  on: 

-  a  global  functional  transformation  in 

which  the  abstract  tree  of  a  program  is  completely 
transformed  by  an  SSL  function;  \ 

-  a  local  attribute  transformation  in 
which  each  node  of  the  abstract  tree  of  an  Adi  program 
synthesizes  a  transformed  node,  the  global 
transformation  therefore  consisting  of  the  attribute  of 
the  root  of  the  program's  abstract  tree. 

The  main  point  to  stress  is  that  whatever  type 
of  transformation  is  used,  a  new  Ada  program  is 
obtained. 


6.2. 1 .  Functional  transformation 

As  we  have  already  seen  in  the  previous  section, 
the  CSG's  SSL  language  is  capable  of  defining  and 
handling  abstract  trees  of  an  abstract  syntax.  Here,  we 
want  to  transform  abstract  trees  in  DIANA  notation. 
This  transformation  can  be  defined  as  a  recursive 
function  on  the  abstract  tree  of  a  program:  for  each 
type  of  node  N ,  we  define  a  transformation  function 
that  defines  N  and,  if  necessary,  recursively  invokes  the 
functions  associated  with  the  types  of  the  child  nodes 
of  N. 

Although  theoretically  possible,  for  the 
moment  this  strategy  can  only  be  implemented  using 
the  CSG.  What  normally  happens  is  that  a 
transformation  function  references  attribute-  associated 
with  a  node  in  the  abstract  tree,  which  may  be  the 
environment  inherited  from  this  node,  for  example. 
However,  referencing  an  inherited  or  synthesized 
attribute  in  an  SSL  function  is  not  possible  using  the 
current  version  of  'he  CSG. 

6.2.2.  Transformation  bv  calculation  of 
attributes 

In  attribute  transformation,  we  only  define  the 
local  equations  required  to  relate  each  node  to  an 
attribute  representing  its  transformation.  Provided  that 
circularity  is  avoided,  an  attribute  definition  can 
reference  other  attributes. 

This  is  the  strategy  that  we  have  adopted.  An 
interesting  feature  is  that  the  abstract  tree  of  the  initial 
Ada  program  is  not  modified,  as  the  Ada  program  of 
the  application  to  be  transformed  is  the  attribute 
associated  with  the  root  of  the  original  Ada  wee. 

6  2.3.  Iransformaiipn  examples 

The  examples  below  are  designed  to  show  how 
an  Ada  program  is  transformed  into  an  equivalent  Ada 
program  by  going  through  the  STRAda  kernel.  The 
first  example  is  a  simple  one  based  on  the  accept 
instruction  only,  and  the  second  example  shows  how 
the  select  instruction  is  transformed. 

Example  1 

type  MSG  is  array  (l..n)  of 
character; 

accept  RETRIEVE  (INFO  :  MSG)  do 
INFO  :=  BUFFER; 
end  RETRIEVE; 
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This  Ada  code  is  translated  into  the  equivalent 
Ada  code; 

declare 

Info  :  msg; 

begin 

Accept_do (Task_Box .entry_RetrIEve, 
Caller_name) ; 

Info  BUFFER; 

ACCEPT_END 

(TASK_Box . entry_Ret rieve, 

Tp_out  *•>  (Tab_pa ram 1  first  «> 
(Info'address,  Info'size), 
Caller_name) ; 

end; 


Example.  2 


The  UNIX  select  primitive,  which  waits  for  a 
message  on  a  set  of  ports,  enables  the  Ada  select 
instruction  to  be  easily  translated  into  the  equivalent 
Ada  code: 


eelect 

whan  S>0  -> 
accept  P  •• 

S  S  -  1; 
or 

accept  V; 

S  S  +  1; 

end  select; 


This  Ada  code  is  translated  into  the  equivalent 
Ada  code: 

declare 

L_ENT  :  LISTE_OF_ENTRIES  (1..MAX); 
NB  :  integer  :«  0; 

ENT_SEL  :  ENTRY_NAME ; 

begin 

if  S>0  then 

NB  NB  +  1; 

L_ENT (NB>  ENTRY_P; 
end  if; 

NB  NB  -1; 


L_ENT (NB)  :=  EMTRY_P; 

ENT_SEL  SELECTT <L_ENT  (1..NB), 

-1) ; 

case  ENT_SEL  is 

when  ENTRY_P  *=>  ACCEPTT  (ENT_SEL)  ; 
S  S  -  1; 

When  ENTRY_V  =*>  ACCEPTT  (ENT_SEL;  ; 
S:*=  S  +  1; 

when  others  =>  raise 
Tasking_error; 

end  case; 
end; 

7.  Processor  assienemeni  for  tasks 


In  this  section,  we  shall  expand  on  the  aspects 
of  processor  assignement.  The  STRAda  approach 
makes  it  easy  to  define  a  generic  processor  assignement 
procedure.  This  generic  procedure  can  be  instantiated  in 
the  following  contexts: 

1  •  Task  control  station 

This  station  is  able  to  locate  tasks  interactively. 
It  provides  operators  with  important  information  that 
will  enable  them  to  determine  their  choices  (processor 
loads,  assignement  of  the  same  processor  for  tasks 
likely  to  communicate  with  the  task  to  be  created,  etc.) 
through  an  ergonomic  man-machine  interface. 

However,  this  mechanism  is  only  useful  for 
tasks  with  long  lifetimes  (e  g.  servers). 

2  -  Configuration  program 

The  configuration  program  is  written  in  a 
separate  phase  of  the  main  program.  It  is  written  in 
Ada  and  consists  of  an  assignement  function  called  by 
the  task  creation  function.  This  method  has  the 
advantage  of  being  valid  for  programs  whatever  their 
lifetime. 

3  -  Automatic  processor  assignement  manager 

The  manager  frees  the  programmer  from  having 
to  worry  about  processor  assignement  if  he/she  so 
desires.  Several  managers  can  be  used,  each  designed 
for  a  specific  situation:  balancing  of  processor  loads, 
grouping  of  tasks  communicating  frequently  on  the 
same  site,  etc.. 
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model  more  close!/  reflects  rendez  vous  than  the  RPC 
8.  Discussion  primitive. 


8.1.  Assessment 

In  this  part,  we  shall  discuss  the  approach 
adopted  for  the  STRAda  project.  As  we  have  already 
seen,  the  STRAda  approach  is  above  all 
transformational:  we  have  not  attempted  to  define  a 
new  language  or  system,  but  simply  studied  how  to 
transform  certain  constructs  of  an  existing  language 
into  constructs  of  an  existing  system.  We  feel  this 
approach  is  a  good  one  for  several  reasons: 

-  familiar,  of  the  shelf  and  widely  used 
compilers  and  systems  can  be  used,  thi  s  ensuring  good 
portability; 

-  it  is  easily  adaptable  to  other  systems: 
we  could  also  consider  transforming  constructs  for 
Chorus  28  or  for  other  real-time  kernels. 

As  for  installation,  we  have  left  aside  the 
problem  of  shared  variables,  task  termination  and  time 
management  ( delay  instruction)  for  the  time  being.  We 
would  stress  that  with  regard  to  shared  variables: 

-  firstly,  certain  off-the-shelf  systems 
now  provide  global  memory  abstraction  over  a 
network; 

-  secondly,  thanks  to  the  minimum 
STRAda  kernel,  we  can  consider  a  schema  in  which 
shared  variables  arc  implemented  as  distributed 
variables  encapsulated  in  remotely  accessible  tasks  and 
transformations  making  it  possible  to  substitute  access 
to  these  shared  variables  by  calls  to  entry  points 
defined  by  the  tasks. 

The  problem  of  task  termination,  however,  is 
trickier,  as  an  algorithm  adapted  to  the  Ada  model  is 
required.  This  point  is  being  studied. 

We  also  made  some  implementation  choices 
that  sometimes  impose  limitations  on  the  system. 
First  of  all,  we  chose  a  UNIX  process  to  implement 
tasks,  even  though  a  thread  more  closely  reflects  the 
nature  of  a  task.  The  reason  for  this  choice  is  one  of 
history:  threads  were  not  yet  supported  by  UNIX  when 
the  Ada  project  was  started.  They  are  still  not 
supported  by  a  lot  of  systems,  and  for  this  reason  they 
would  have  reduced  STRAda's  portability. 

We  also  chose  sockets  instead  of  RPCs 
(Remote  Procedure  Calls).  This  is  related  to  the  choice 
of  Ada  rendez-vous  as  the  mechanism  for 
communication  between  remote  tasks:  tne  socket 


Other  limitations  were  imposed  on  the  use  ol 
the  task  mot,  :.  The  COUNT  attribute  associated  with 
the  queue  is  m,  implemented  as  it  is  impossible  to  tell 
the  size  of  the  queue  on  the  socket.  Flexible  arrays  are 
not  accepted  as  a  rende/.-vous  parameter.  The  same 
applies  to  access  types,  with  the  exception  of  task 
access  types,  since  the  task  names  are  replaced  during 
transformation  by  a  single  name  over  the  entire 
distributed  environment.  Finally,  exceptions  that  are 
not  pre-defined  arc  not  fully  propagated.  When  a  non 
prc-tiiTined  exception  has  to  be  propagated  from  one 
site  to  another,  the  exception  USFR  J-.RROR  is  raised 
at  the  remote  site. 


Like  all  other  projects  studying  distribution 
with  Ada,  STRAda  attempts  to  provide  distributed 
applications  with  what  was  missing  from  Ada83.  The 
definition  of  a  new  Ada  standard  is  near  completion. 
Wc  already  know  that  most  of  the  shortcomings  of  the 
current  version,  with  respect  to  distributed  systems, 
will  be  fixed  by  Ada9X.  Here,  wc  shall  attempt  to 
assess  how  Ada9X  will  respond  to  the  needs  of 
distributed  applications  and  to  what  extent  STRAda 
will  continue  to  be  of  use  once  Ada9X  has  been 
released. 

Unlike  Ada83,  Ada9X  defines  a  distribution 
model.  The  language  has  a  distribution  unit,  called  a 
partition,  and  a  model  for  communicating  between 
partitions.  On  compilation,  packages  arc  put  into  the 
following  classes: 

-  pure  packages: 

-  remote  call  interface  packages; 

-  shared  passive  packages; 

-  normal  packages. 

It  is  only  at  the  link  editing  stage  that  the 
partitions  are  made  up  by  groups  of  library  units. 
Partitions  may  be: 

-  active  partitions,  which  arc  pseudo- 
independent  programs  able  to  make  or  receive  remote 
.alls; 

-  shared  passive  partitions,  used  to 
manage  data  in  shared  memory  areas. 

The  application  programmer  has  to  provide  the 
partition  communication  sub-system  interface  for 
transferring  messages  between  partitions.  The 
compilation  system  uses  this  interface  to  create 
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parameter  passing  stubs  automatically.  This  means 
that  a  standard  distribution  mode!  can  be  used  without 
being  dependent  on  a  special  type  of  distribution 
environment.  This  model  solves  the  problems 
encountered  when  attempting  to  design  distributed 
applications  with  Ada83,  for  two  reasons: 

-  portability  is  improved  by  the  use  of  a 
standard  distribution  model;  only  the  body  of  the 
standard  communication  sub-system  interface 
RPC_SUPPORT  needs  to  be  supplied  when  changing 
to  another  distributed  environment; 

-  static  and  dynamic  reconfiguration  is 
simpler  in  Ada9X  than  in  Ada33,  as  in  Ada9X  the 
software  is  not  assigned  to  specific  hardware  until  after 
code  has  been  compiled. 

Static  reconfiguration  with  Ada9X  is  achieved 
simply  by  changing  the  partitioning  specifications  or 
by  allocating  processors  so  that  the  distributed  program 
can  be  run  on  a  different  configuration.  For  dynamic 
reconfiguration,  we  need  to  be  able  to  create  dynamic 
links  between  partitions.  This  is  done  either  by  using 
subroutine  access  types  or  tagged  class  access  types. 

Exceptions  are  used  in  inter-partition 
communication.  An  exception  raised  on  calling  a 
remote  subroutine  is  propagated  to  the  caller  program. 
Similarly,  a  COMMUNICATJON_FRROR  exception 
is  raised  in  any  exceptional  circumstances  caused  by  a 
network  failure  or  a  remote  hardware  failure. 

'rhe  Ada9X  distribution  model  is  completely 
independent  of  the  parallelism  model.  This  makes 
implementation  easier,  as  the  model  chosen  is  well 
suited  to  distributed  systems.  On  the  other  hand,  in 
applications  where  distribution  is  required  only  to 
improve  response  times  or  fo.  more  efficient  use  of 
hardware,  it  would  be  useful  to  be  able  to  free  the 
programmer  from  distribution  issues.  This  is  where 
STRAda  may  continue  to  be  helpful  once  Ada9X  has 
arrived.  STRAda  makes  it  possible  to  distribute  any 
parallel  unit,  meaning  that  a  distribution  system  can 
remain  totally  transparent. 


9.  CfljKimittn 


A  prototype  of  the  STRAda  project  is  currently 
operational.  We  have  tested  several  standard  parallel 
programs,  like  an  adaptation  of  the  dining 
philosophers’  problem  in  a  physically  distributed 
environment. 


A  practical  aspect  that  we  feel  is  of  interest 
concerts  transformations  for  existing  real-time  kernels 
or  operating  systems;  this  would  make  it  possible  to 
write  or  reuse  applications  written  in  a  high-level 
language,  and  to  reuse  existing  and  dedicated  real-time 
kernels  for  certain  types  of  architecture. 

We  think  that  STRAda  provides  some  solutions 
to  the  problems  of  distribution  with  Ada;  this  will  still 
be  the  case  when  Ada9X  has  been  released,  since  the 
approach  used  for  STRAda  is  a  complement  to  that 
used  for  Ada9X. 

Finally,  from  a  theoretical  point  of  view,  i» 
would  be  interesting  to  validate  the  corresponding 
transformations. 

lr.  conclusion,  the  STRAda  project  has  allowed 
us  to  research  and  establish  links  between  different 
areas  of  information  technology,  by  working  on  both 
system  and  language  aspects.  This  experience  proved  to 
be  very  rewarding. 
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MATHEMATICS,  ENGINEERING,  AND  SOFTWARE  DEVELOPMENT 

Michael  J.  Lutz 

Rochester  Institute  of  Technology 
Rochester,  New  York 


Abstract:  While  modern  engineering  prac¬ 
tice  owes  much  to  both  science  and  mathe¬ 
matics,  it  is  not  identical  with  either.  It  is 
the  thesis  of  this  paper  that  failure  to  recog¬ 
nize  the  differences  between  mathematics  on 
one  hand,  and  engineering  on  the  other,  is  the 
root  cause  of  the  failure  to  transfer  comput¬ 
ing  theory  into  industrial  practice.  Only  by 
understanding  the  nature  of  the  engineering 
method  and  its  relationship  to  mathematics 
can  we  hope  to  infuse  rigor  into  software  de¬ 
velopment,  and  in  turn  transform  a  craft  into 
an  engineering  profession. 

Introduction 

A  recurring  theme  in  discussions  of  software  practice  is 
the  need  to  provide  a  more  “scientific"  foundation  for 
the  field.  In  part  this  viewpoint  is  based  on  the  patent 
success  of  science  in  advancing  modern  engineering. 
One  obvious  conclusion  is  that  software  development 
requires  a  similar  rigorous,  mathematical  foundation 
before  it  can  truly  be  called  software  engineering.  ^ 
Supporters  of  this  position  are  disconcerted  by  the  fact 
that  theoretical  results  have  little  effect  on  the  state 
of  the  practice. 

It  is  my  thesis  that  at  the  failure  of  theory  t^o  influ¬ 
ence  practice  is  rooted  in  a  lack  of  appreciation  of  the 
fundamental  differences  between  science  (specifically, 
mathematics)  and  engineering.  Indeed,  I  believe  that 
at  least  some  of  the  resistance  to  formalism  is  based 
on  sound  engineering  principles,  however  poorly1,  artic¬ 
ulated. 

Many  of  those  advocating  increased  rigor,  myself  in¬ 
cluded,  were  trained  as  mathematicians  or  scientists, 
not  as  engineers.  Given  this,  it  is  important  to  investi¬ 
gate  the  methods  of  engineering  and  their  relationship 
to  science  and  mathematics.  Without  such  an  under¬ 
standing,  attempts  to  apply  theory  to  the  engineering 
of  software  are  naive  at  best,  and  counterproductive  at 


worst.  However,  armed  with  such  knowledge,  it  will  be 
easier  to  spot  areas  where  theory  can  have  the  greatest 
positive  effect. 

I  have  chosen  the  field  of  formal  methods  to  exemplify 
both  the  problems  and  promises  of  theory  as  applied  to 
practice.  While  this  is  the  area  with  which  I  am  most 
familiar,  I  firmly  believe  that  similar  comments  apply 
to  other  applications  of  mathematics  and  science.  For 
instance,  a  recent  book  on  software  reliability  directly 
addresses  the  needs  of  practitioners.^ 

The  next  section  provides  a  brief  introduction  to  the 
world  of  formal  methods,  providing  a  broad  sketch  of 
the  method  types,  as  well  as  the  role  each  type  may 
play  in  software  development.  A  discussion  of  the  engi¬ 
neering  method  follows,  with  particular  attention  paid 
to  the  role  of  science.  This  leads  naturally  to  a  dis¬ 
cussion  of  the  use  of  formal  methods  in  the  context  of 
the  engineering  method.  In  particular,  a  strategy  is 
proposed  for  the  effective  transfer  of  formal  methods 
to  standard  practice. 

An  Overview  of  Formal  Methods 

Any  discussion  of  formal  methods  requires  a  definition 
of  this  term: 

A  formal  method  is  a  mathematical  system 
and  associated  rules  of  inference  used  to 
model  and  reason  about  some  characteristic 
of  a  software  system. 

While  many  such  systems  are  applicable  to  software 
development,  the  presentation  will  concentrate  on 
those  describing  functional  behavior.  This  is  where  the 
majority  of  work  to  date  has  taken  place,  and  where, 
as  a  consequence,  the  mathematical  models  are  most 
mature. 

Even  with  this  restricted  foeur,  however,  further  cat¬ 
egorization  is  desirable.  Perhaps  the  clearest  distinc- 
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tion  is  between  the  model-baaed  approaches  such  as 
and  VDM,®  and  algebraic  (equational  systems)  such  as 
OBJ.®  Model  based  systems  use  a  collection  of  math¬ 
ematical  entities  (sets,  relations,  sequences,  etc.)  as 
building  blocks  to  construct  problem-specific  models. 
Algebraic  systems  are  based  on  equations  relating  val¬ 
ues  drawn  from  different  aorta.  As  a  rule,  algebraic 
systems  are  used  primarily  to  define  the  semantics  of 
abstract  data  types  (ADTs),  whereas  model  based  the¬ 
ories  are  employed  for  system  level  descriptions.  Of 
course,  there  is  large  overlap  in  the  problems  to  which 
these  two  approaches  apply. 

Competing  methods  can  also  be  classified  by  the  soft¬ 
ware  development  phases  where  they  are  most  useful. 
The  Z  system,  for  example,  is  most  frequently  used 
for  system  specification,  though  approaches  exist  to 
carry  it  through  design  and  implementation.  Similarly, 
VDM  also  spans  the  specification  and  design  phases, 
though  its  emphasis  is  clearly  on  the  latter.  Finally, 
Dijkstra’s  guarded  command  language^  is  primarily 
for  proofs  of  (implementation)  correctness,  using  a  for¬ 
mal  design  specification  already  at  hand. 

The  relative  importance  of  modeling  vs.  reasoning  pro¬ 
vides  a  third  perspective.  All  formal  methods  combine 
modeling  and  reasoning,  yet  there  is  a  discernible  shift 
in  emphasis  from  the  former  to  the  latter  as  activi¬ 
ties  proceed  from  analysis  to  implementation.  Z  and 
VDM  are  often  presented  as  tools  for  precise  and  con¬ 
cise  modeling  of  a  system  or  its  components.  In  ad¬ 
dition,  they  are  also  used  to  verify  design  steps,  by 
showing  the  formal  design  model  mirrors  the  formal 
specification  in  all  essential  properties.  At  the  im¬ 
plementation  stage,  where  a  system  like  Dijkstra’s  is 
applicable,  the  system  has  been  partitioned  into  man¬ 
ageable  sized  components,  each  of  with  a  precise  spec¬ 
ification.  Here  the  modeling  activity  is  implicit,  while 
the  inference  rules  highlight  the  role  of  formal  reason¬ 
ing  in  simultaneously  creating  algorithms  and  proving 
their  correctness. 

A  final  role  that  formal  methods  can  play  is  in  cata¬ 
loging  systems  of  reusable  components.  The  analogy 
here  is  to  a  standard  IC  component  catalog;  an  ex¬ 
ample  would  be  using  the  two-tiered  Larch  system® 
to  describe  interfaces  of  C  modules.  By  providing 
complete,  accurate,  and  concise  descriptions  of  library 
components,  formal  methods  help  developers  evaluate 
the  fitness  of  components  for  their  application.  Note 
that  this  use  of  formal  methods  is  primarily  one  of 
modeling. 

There  is  a  common  thread  through  all  of  the  view¬ 


points  above.  In  all  cases,  mathematics  (specifically 
discrete  mathematics)  is  used  to  characterize  the  be¬ 
havior  of  a  software  product.  The  question  remains 
whether  or  not  these  systems  are  useful  as  engineering 
tools.  To  answer  this  question,  we  must  first  determine 
what  constitutes  engineering,  and  how  mathematics 
supports  engineering  endeavors. 

The  Engineering  Method 

If  engineering  disciplines  are  to  serve  as  guides  for  soft¬ 
ware  development,  then  an  investigation  of  the  engi¬ 
neering  method  is  in  order.  That  is,  the  focus  must 
be  on  the  sorts  of  problems  that  require  engineers, 
and  how  engineers  approach  such  problems.  We  are 
less  concerned  with  the  goals  of  engineering  than  with 
the  processes  by  which  engineers  achieve  these  goals. 
With  respect  to  formal  methods,  the  question  is  even 
more  specific:  what  is  the  role  of  mathematics  and  sci¬ 
ence  in  the  everyday  activities  of  practicing  engineers? 
The  answer  should  help  determine  if  and  when  formal 
methods  can  be  useful  in  software  development. 

A  problem  with  this  investigation  is  that  most  engi¬ 
neers  are  not  introspective  by  nature.  In  addition 
while  the  philosophy  of  science  is  a  respectable  aca¬ 
demic  discipline,  similar  work  on  the  philosophical 
foundations  of  engineering  is  rare  indeed.  Yet  with¬ 
out  such  a  perspective,  it  is  presumptuous  for  non¬ 
engineers  to  speak  of  any  practice  as  promoting  soft¬ 
ware  engineering.  Fortunately,  there  are  professional 
engineers  who  have  written  about  their  profession  and 
its  workings.®1  ^ 

A  primary  source  for  my  investigations  is  a  short  work 
by  Billy  Vaughn  Koen.  In  this  75  page  monograph, 
Koen  tries  to  define  the  engineering  method  in  a  man¬ 
ner  that  is  acceptable  to  professional  engineers  and 
accessible  to  the  public  at  large.  In  Koen’s  view,  the 
engineering  method  is: 

The  strategy  for  causing  the  best  change  in 
a  poorly  understood  or  uncertain  situation 
within  the  available  resources. 

To  an  engineer,  best  is  not  absolute,  but  relative  to  the 
engineer’s  ability  to  assess  and  balance  both  technical 
and  societal  issues.  Thus  professional  engineers  fre¬ 
quently  disagree  over  proposed  designs,  but  primarily 
on  the  basis  of  which  aspects  are  significant  and  which 
can  be  dismissed  as  inconsequential. 

Koen  then  asserts  that  the  engineering  method  can 
only  be  understood  as  the  application  of  appropriate 
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engineering  heuristics.  He  defines  the  “state-of-the- 
art”  (or  sota)  as  the  heuristics  available  to  the  engi¬ 
neering  profession  at  a  specific  point  in  time.  Each 
engineer  has  his  or  her  own  sota,  which  reflects  the 
heuristics  he  or  she  can  bring  to  bear  on  a  problem. 
An  engineer  engages  in  best  practice  to  the  extent  that 
his  or  her  individual  sota  intersects  with  that  of  the 
profession  as  a  whole. 

Koen  draws  a  strong  contrast  between  this  pragmatic 
approach  and  the  processes  of  science.  Two  conflict¬ 
ing  scientific  theories  cannot  both  be  correct:  at  least 
one  is  wrong.  The  victorious  theory  in  any  scientific 
debate  is  the  one  which  explains  a  broader  spectrum 
of  phenomena,  or  which  provides  a  simpler  model  of 
the  same  phenomena. 

Engineering  heuristics,  however,  are  never  right  or 
wrong.  Instead,  they  are  more  or  less  applicable  in  a 
specific  context.  Indeed,  many  engineering  heuristics 
are  discarded  scientific  theories  that  prove  sufficient  for 
the  task  at  hand  (e.g.,  Newtonian  physics).  What  is 
more,  the  engineering  sota  can  accommodate  conflict¬ 
ing  heuristics,  with  higher  level  heuristics  to  determine 
when  each  is  used. 

There  are  two  key  consequences  of  Koen ’s  perspective. 
First,  engineering  practice  has  no  absolute  measure 
for  evaluation,  if  for  no  other  reason  than  the  sota  is 
undergoing  constant  change.  Second,  the  heuristics 
used  in  a  particular  case  depend  on  more  than  purely 
technical  factors:  societal  norms,  resource  constraints, 
and  evaluation  of  risks.  Koen  mentions  the  Golden 
Gate  Bridge,  which  is  not  really  made  of  gold  despite 
that  metal’s  advantageous  properties. 

Thus,  in  Koen’s  view,  a  concept,  technique,  or  ap¬ 
proach  is  judged  by  its  relevance  to  the  task  at  hand. 
And,  of  course,  as  judgement  is  involved  there  is  al¬ 
ways  a  chance  things  may  go  sour.  What  distinguishes 
engineering  is  the  evolution  of  heuristics  that  succeed 
much  more  often  than  they  fail. 

Koen  discusses  a  variety  of  heuristics  are  various  levels 
of  detail.  Some  are  quite  specific  to  a  branch  of  engi¬ 
neering;  those  for  software,  for  instance,  include  avoid¬ 
ing  gotos  and  writing  procedures  that  will  fit  on  one 
screen.  However,  there  are  also  higher-level  heuristics 
shared  by  most  engineering  disciplines: 

•  Work  at  the  margin  of  solvable  problems  (don’t 
stretch  too  far  beyond  what  is  known  to  work). 

•  Make  small  changes  to  the  state-of-the-art  (don’t 
make  radical  changes  to  the  process  or  the  prod¬ 
uct). 


•  Allocate  resources  as  long  as  the  cost  of  not  know¬ 
ing  exceeds  the  cost  of  finding  out  (expend  re¬ 
sources  to  evaluate  and  reduce  risk). 

Many  of  these  are  directly  applicable  to  software  de¬ 
velopment.  Firms  that  make  radical,  uncontrolled  pro¬ 
cess  changes  often  regret  their  impetuousness.  Simi¬ 
larly,  prototypes  are  promoted  as  a  way  of  reducing 
the  risk  that  delivered  products  will  not  satisfy  the 
customer. 

One  of  Koen’s  heuristics  discusses  the  use  of  science 
(and  by  extension  mathematics).  Koen  draws  a  sharp 
distinction  between  applied  science  on  one  hand  and 
engineering  on  the  other: 

The  thesis  that  engineering  is  applied  science 
fails  because  scientific  knowledge  has  not  al¬ 
ways  been  available,  is  not  always  available 
now,  and  because,  even  if  available,  it  is  not 
always  appropriate  for  use. 

The  engineer  recognizes  both  science  and  its 
use  as  heuristics,  although  very  important 
ones,  to  be  applied  only  when  appropriate. 

Examples  abound  of  scientific  and  mathematical  the¬ 
ories  that  took  decades,  even  centuries,  to  be  incor¬ 
porated  into  engineering  practice.  Many  applications 
of  Fourier  analysis,  for  example,  had  to  await  the  de¬ 
velopment  of  digital  computers  and  the  dissemination 
of  the  Cooley-Tukey  FFT  algorithm.  Similar  obser¬ 
vations  may  be  made  about  the  use  of  finite  element 
analysis  in  mechanical  design. 

In  summary:  engineers  do  not  ignore  problems  simply 
because  scientific  theory  is  lacking,  nor  do  they  blindly 
apply  all  scientific  results  as  they  appear.  Science  is 
a  powerful  tool  for  engineering,  but  the  tool’s  use  is 
guided  by  heuristics  that  also  consider  time,  cost,  and 
other  resource  constraints. 

While  this  discussion  has  been  based  on  Koen’s  work, 
his  opinions  are  supported  by  other  commentators  cn 
the  engineering  scene.®-  ^  In  all  cases,  the  crit¬ 

ical  issue  in  engineering,  and  the  focus  of  engineer¬ 
ing  creativity  is  on  design ,  which  can  only  be  under¬ 
stood  in  the  context  of  engineering  judgement.  This 
judgement  is  co-terminus  with  the  discriminating  use 
of  heuristics,  which  in  turn  provides  a  useful  reference 
point  when  considering  the  application  of  computing 
theory  in  software  engineering.  The  particular  ques¬ 
tion  we  must  address  is  how  to  increase  the  value  of 
the  heuristic  “use  formal  methods.” 
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Forma!  Methods  and  Software  Engineering 

It  is  safe  to  say  that  use  of  forma!  methods  is  not 
common  in  industry.  The  previous  section  gives  us 
clues  as  to  why  this  is  so.  First,  formal  methods  are  a 
dramatic  departure  from  current  practice,  and  this  is 
counter  to  the  “small  change”  heuristic.  Second,  while 
formal  methods  are  elegant  science,  most  practitioners 
do  not  believe  they  are  cost-effective.  A  recent  book 
contains  a  scathing  attack  on  formalism  on  just  such 
grounds. 

There  are  many  reasons  for  such  skepticism,  not  all 
of  which  are  easily  dismissed.  Part  of  the  problem 
is  the  emphasis  (at  least  in  the  U.S.)  on  formal  pro¬ 
gram  proofs.  Not  only  do  such  proofs  appear  tedious 
and  time-consuming,  they  presuppose  a  formal  speci¬ 
fication  without  describing  how  such  specifications  are 
themselves  developed.  What  is  more,  such  proofs  oc¬ 
cur  at  the  implementation  stage  of  the  development 
life-cycle,  which  consumes  a  relatively  small  propor¬ 
tion  of  a  project’s  resources.  Finally,  proofs  do  little 
to  increase  confidence  that  the  specifications  are  cor¬ 
rect,  or  that  the  design  reflects  all  requirements.  Yet 
is  is  increasingly  clear  that  specification  and  design  er¬ 
rors  are  both  more  expensive  to  repair  and  more  per¬ 
nicious  in  their  effects  than  those  introduced  during 
implementation. 

With  these  criticisms  in  mind,  and  remembering  the 
key  tenets  of  the  engineering  method,  it  is  feasible  to 
consider  how  formal  methods  might  be  most  effectively 
used  in  software  development.  The  following  sections 
sketch  a  three-phase  strategy  to  increase  the  accep¬ 
tance  and  application  of  formal  methods. 

Emphasis  on  Modeling 

As  mentioned  above,  it  is  skepticism  about  proofs  (i.e. , 
formal  reasoning)  that  dominates  discussions  of  formal 
methods.  One  way  to  address  this  issue  head-on  is  to 
concentrate  on  the  modeling  aspect.  First,  it  is  eas¬ 
ier  to  develop  and  read  formal  specifications  ;han  it  is 
to  reason  about  their  properties.  Indeed,  it  has  been 
argued  that  using  mathematics  as  a  descriptive  tool 
is  valuable  in  and  of  itself,  as  the  result  is  increased 
clarity  and  reduced  ambiguity.  Second,  it  is  eas¬ 
ier  to  gain  acceptance  for  a  new  technology  when  it 
addresses  front-end  problems. 

The  prerequisite  mathematics  are  the  same  for  both 
formal  specifications  and  proofs  of  correctness.  How¬ 
ever,  the  level  of  description  is  higher  and  the  potential 
for  improved  quality  more  obvious  in  the  case  of  spec¬ 


ifications.  Once  the  use  of  formalism  as  a  descriptive 
tool  is  accepted,  it  becomes  much  easier  to  incremen¬ 
tally  address  issues  of  formal  consistency  analysis  and 
verified  design.  This  may,  in  time,  lead  all  the  way 
to  formal  proofs  of  some  components.  Note,  however, 
that  in  all  cases  the  decision  of  whether  or  not  to  for¬ 
mally  verify  a  particular  component  remains  heuristic. 

The  most  frequently  cited  case  of  industrial  formal 
methods  is  the  CICS  reengineering  work  at  IBM’s 
Hursley  Labs  in  the  United  Kingdom,  performed  in 
conjunction  with  Oxford  University.^  In  this  case, 
Z  is  used  to  model  the  CICS  components  being  reengi¬ 
neered.  While  refinements  to  Dijkstra’s  language  are 
part  of  the  process,  it  appears  that  the  modeling  com¬ 
ponent  is  most  important.  In  particular,  Z  is  now  be¬ 
ing  used  to  provide  precise  interface  specifications  for 
CICS  application  developers. 

Consumable  Mathematics 

Another  impediment  to  increased  use  of  formal  meth¬ 
ods  is  the  level  of  mathematical  sophistication  re¬ 
quired.  In  most  engineering  disciplines,  practitioners 
become  master  users  of  high  level  mathematical  and 
scientific  results.  Engineers  use  handbooks  and  other 
reference  material  to  access  the  essence  of  a  theory;  de¬ 
riving  necessary  information  from  scratch  is  unusual. 
Even  in  cases  where  engineers  must  apply  fundamental 
principles,  they  do  so  at  an  abstract  level  (e.g.,  using 
general  differentiation  and  integration  rules). 

Most  formal  methods,  however,  require  intimate  and 
detailed  knowledge  of  fundamental  mathematical  the¬ 
ories.  This  may  be  a  natural  (if  regrettable)  conse¬ 
quence  of  the  immaturity  of  these  methods.  Still,  the 
fact  remains  that  engineers  rarely  resort  to  the  limit 
definition  of  differentiation.  Similarly,  we  should  not 
expect  software  engineers  to  routinely  employ  the  low- 
level  inference  rules  of  natural  deduction. 

An  example  of  providing  such  higher  level  abstractions 
is  the  work  on  instrumentation  models  at  Tektronix. 
The  creation  of  such  models  requires  a  deep  knowledge 
of  Z  semantics.  Development  engineers,  however,  can 
simply  employ  these  models,  having  been  assured  that 
they  rest  on  firm  foundations. 

Engineers  are  not  and  should  not  be  mathematicians. 
Instead,  the  formal  methods  community  must  develop 
higher-level  “consumable  mathematics”  corresponding 
to  continuous  mathematics  for  traditional  engineering. 
It  is  heartening  to  see  that  work  is  progressing  on  this 
front  .«■  20 
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Education  of  Future  Professionals 

The  role  of  education  in  successful  technology  trans¬ 
fer  is  vital.  There  are  many  instances  where  technol¬ 
ogy  introduced  in  the  classroom  supported  significant 
change  in  industry  within  a  few  years.  The  success  of 
the  Unix  system,  at  least  in  the  engineering  worksta¬ 
tion  marker,  is  >n  large  meat  ure  due  to  the  wide-scale 
use  of  the  system  by  academia  in  the  1970’s.  It  does 
not  matter  whether  one  thinks  this  was  good  or  bad; 
what  is  significant  is  that  academic  experiences  led  to 
expectations  that  we*e  eventually  met  by  industry. 

Given  this,  it  is  crucial  that  students  be  exposed  to 
formality  in  such  a  way  that  they  consider  it  an  im¬ 
portant  component  of  their  intellectual  toolkits.  If  this 
is  not  ro,  there  is  a  risk  that  the  next  generation  of 
developers  will  be  as  skeptical  as  their  predecessors 
about  formal  methods.  Thus,  the  prescription  above 
is  as  valid  for  software  engineering  curricula  as  it  is 
for  industrial  acceptance.  That  is,  instructors  should 
stress  modeling  early,  postponing  formal  proofs  untii 
such  time  as  their  significance  can  be  demonstrated. 
The  result:  more  graduates  who  appreciate  whs*  for¬ 
mal  methods  have  to  offer  and  who  can  articulate  these 
advantages  during  their  professional  careers. 

I  have  adopted  such  a  descriptive  approach  in  two 
courses  I  teach  at  RIT.  The  first  course,  an  intro¬ 
duction  to  design  and  implementation  for  sophomores* 
uses  simple  pre  and  post  conditions  to  define  the  con¬ 
tract  between  clients  and  implementors  of  modules  h 
addition,  implementors  are  required  to  develop  invari¬ 
ants  that  characterize  the  legal  internal  states  of  their 
modules.  While  our  teaching  language  is  Moduia-2, 
the  spirit  is  that  of  CLU-based  work  at  MIT.^  I  con¬ 
sider  this  technique  successful,  as  many  students  have 
carried  these  practices  over  to  later  courses  taught  by 
others. 

The  second  course  is  on  apt  dfication  and  design,  taken 
by  juniors  and  seniors  in  the  software  engineering  con¬ 
centration.  In  this  course,  I  introduce  modeling  in  Z, 
using  the  text  by  Potter,  et.  al.^.  Later,  when  object- 
oriented  technology  is  presented,  I  incorporate  Z  as  a 
functional  specification  tool,  using  the  work  of  Hayes 
and  Coleman  on  coherent  object-oriented  analysis.^ 
The  notion  of  design  refinement  and  functional  verifi¬ 
cation  is  touched  upon,  but  always  in  the  context  of 
modeling  a  problem  solution.  The  results  are  gratify¬ 
ing:  surveys  at  the  beginning  and  end  of  the  course 
show  a  definite  shift  towards  the  acceptance  of  for¬ 
mality  as  useful  in  practice.  Though  the  students  are 
skeptical  about  their  ability  to  transfer  this  technol¬ 


ogy  to  industry,  the  seeds  of  this  transfer  have  been 
planted. 

Conclusion 

A  formal,  scientific  foundation  is  required  if  software 
development  is  ever  to  be  classified  as  engineering. 
However,  developers  of  this  foundation  must  be  aware 
of  the  processes  underlying  engineering  endeavors  if 
the  resulting  theory  is  to  become  part  of  standard 
practice.  Based  on  an  investigation  of  the  engineer¬ 
ing  method,  this  paper  has  proposed  one  strategy 
for  achieving  such  integration  with  respect  to  formal 
methods.  Similar  strategies  must  be  defined  for  other 
areas  of  computer  science  so  that  a  modern  software 
engineering  discipline  can  emerge. 
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Summary 

Software  produced  for  the  U.S.  military 
services  is  one  of  the  key  components  of 
national  defense,  and  will  play  an  increasing 
role  in  all  future  military  operations.  It  is 
therefore  of  critical  importance  to 
understand  the  key  factors  which  influence 
the  costs,  schedules,  and  quality  levels  of 
software  production. 

Unfortunately,  historical  measures  based  on 
"Lines  of  Source  Code"  have  tended  to 
conceal  vital  information,  and  have  slowed 
software  research  efforts.  Improved  metrics 
based  on  the  functional  content  of  software 
are  now  available.  These  new  metrics  reveal 
that  coding  itself  is  not  the  major  cost  driver 
of  large-scale  software  production.  Both 
paperwork  and  defect  removal  costs 
outweigh  pure  coding  by  substantial  margins 
for  military  software. 

Introduction 

Measurement,  metrics,  and  statistical  analysis 
of  data  are  the  basic  tools  of  science  and 
engineering.  Unfortunately,  the  software 
industry  has  existed  for  almost  50  years  with 
a  dismaying  paucity  of  measured  data,  with 


metrics  that  have  never  been  formally 
validated,  and  with  statistical  techniques  that 
are  at  best  questionable. 

As  the  20th  century  draws  to  a  close,  it  is 
desirable  for  the  phrase  "software 
engineering"  to  cease  being  an  oxymoron, 
and  become  a  valid  description  of  a  true 
engineering  discipline.  An  important  step  in 
that  direction  will  be  to  evaluate  and  validate 
all  of  the  common  metrics  and  measurement 
techniques  for  software  under  controlled 
conditions,  in  order  to  select  a  standard  set 
that  can  be  used  with  little  or  no  ambiguity 
and  with  minimal  subjectivity. 

Consider  some  of  the  basic  metrics  that 
confront  us  in  a  normal  day.  Upon  arising, 
we  may  check  the  outside  temperature  and 
perhaps  note  the  barometric  pressure  to 
judge  if  it  will  rain.  At  breakfast,  we  may 
think  about  the  cholesterol  levels  and  the 
calories  in  the  food  we  eat.  If  w’e  purchase 
gasoline  on  the  way  to  work,  we  perhaps 
consider  the  octane  rating  of  the  fuel  we  are 
purchasing.  We  might  also  reflect  on  the 
horsepower  of  the  automobile  engine. 

All  of  the  above  metrics  are  interesting  in 
several  respects:  1)  They  are  synthetic 
metrics  which  deal  with  invisible  phenomena 
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that  cannot  be  counted  directly;  2)  Most 
adult  humans  understand  the  significance  and 
basic  meaning  of  the  metric;  3)  Very  few 
individuals  (less  than  1%)  humans  know  how 
to  calculate  these  metrics  or  understand  their 
mathematical  derivations. 

Now  consider  the  metrics  history  of  software 
engineering.  Prior  to  the  1970's,  the  phrase 
"software  engineering"  did  not  exist.  Those 
of  us  in  the  field  were  simply  called 
"programmers." 

The  only  metrics  that  we  used  were  simple 
natural  metrics  such  as  integers.  We  tended 
to  use  lines  of  code  because  we  wrote  our 
programs  on  special  programming  tablets 
where  the  lines  were  clearly  visible  and  often 
numbered.  Some  programming  languages 
such  as  Basic  could  not  even  be  used  without 
line  numbers. 

In  the  1960's  and  1970's,  fairly  low-level 
languages  such  as  Assembly,  JOVIAL,  and 
FORTRAN  were  being  used  for  the  bulk  of 
military  programming.  The  effort  devoted 
to  programming  and  code-related  work  was 
the  dominant  activity  of  software.  Other 
activities  such  as  requirements,  design,  and 
user  documentation  were  seldom  measured 
at  all. 

When  non-coding  activities  were  measured, 
we  used  simple  natural  metrics  such  as 
integer  counts  of  the  pages  or  words. 
Graphics  seldom  occurred  in  commercial 
software,  and  topics  such  as  reusable  code, 
object-oriented  languages,  pull-down  menus, 
graphical  interfaces,  mice,  etc.  were  still  in 
the  future. 

In  the  1980's  and  early  1990's,  an  explosion 
of  new  languages,  n.-v  methods,  and  new 


approaches  changed  the  work  of  software 
development  in  profound  ways. 

By  the  start  of  the  1990  decade  more 
powerful  languages  such  as  Ada.  Objective 
C,  C++,  and  Modula  2  were  being  used. 
New  CASE  tools  and  I-CASE  tools  were 
available,  which  offered  significant  new 
capabilities  to  software  engineers.  New 
standards  such  as  DoD  2167  A  were  in  effect 
for  military  software,  and  the  ISO  9000 
standard  series  was  starting  to  be  deployed 
for  civilian  software. 

These  new  approaches  made  profound 
changes  in  the  cost  and  effort  structure 
required  for  software  production  and 
maintenance.  The  tasks  associated  with  pure 
coding  were  being  reduced  almost  daily. 
However,  the  tasks  associated  with  planning 
and  specification  preparation  were  increasing 
daily  as  well. 

Unfortunately,  attempts  to  model  these 
profound  changes  in  the  software  paradigm 
using  traditional  "Lines  of  Source  Code" 
metrics  discovered  deep  mathematical 
problems  with  the  metric  itself.  LOC  metrics 
were  proved  to  have  a  built-in  bias  which 
penalized  more  powerful  languages  such  as 
Ada.  LOC  metrics  also  failed  to  deal  with 
the  enormous  costs  and  resources  devoted  to 
plans,  specifications,  and  other  forms  of 
software  paperwork. 

The  first  powerful  synthetic  metric 
developed  for  software  was  the  Function 
Point,  which  was  created  in  the  middle 
1970's  by  Allan  Albrecht  and  his  colleagues 
at  IBM.  This  metric  was  placed  in  the  public 
domain  in  October  of  1979  at  a  joint 
SHARE/GUIDE/IBM  conference  in 
Monterey,  California  (1). 
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If  future  historians  want  to  explore  the 
evolution  of  software  engineering  as  a  true 
engineering  discipline,  October  14th  1979  is 
a  strong  contender  to  be  considered  the 
exact  starting  point.  Allan  Albrecht's 
presentation  in  Monterey  marks  the  first  day 
in  software  history  than  an  effective  synthetic 
metric  for  software  was  publicly  stated. 

Problems  with  "Lines  of  Source  Code" 
Metrics 

The  subjectivity  of  "Lines  of  Source  Code" 
can  be  illustrated  by  the  following  analogy: 
Ask  a  software  engineer  or  software 
manager  a  basic  question:  "Is  the  speed  of 
light  the  same  in  the  United  States,  and 
Germany?"  Obviously  the  speed  of  light  is 
the  same  in  every  country. 

Then  ask  the  following  question:  "Is  a  Line 
of  Source  code  the  same  in  the  United  States 
and  Germany?"  The  answer  to  this  question 
is,  "No,  it  is  not" 

Software  articles  and  research  in  Germany 
has  tended  to  use  physical  lines  more  often 
than  logical  statements,  while  the  reverse  is 
true  for  the  U  S.  and  Japan. 

There  have  been  other  metrics  that  differed 
from  country  to  country,  such  as  U  S. 
gallons  and  Imperial  gallons.  Also  statute 
miles  and  nautical  miles  differ  significantly. 
These  differences  are  common  knowledge, 
while  the  differences  in  "Lines  of  Source 
Code"  definitions  are  comparatively  obscure, 
and  sometimes  not  fully  stated  by  software 
authors. 

The  most  widely  used  software  metric  since 
the  industry  began  has  been  Lines  of  Source 
Code,  or  LOC.  Either  this  metric  or 


"KLOC"  (where  K  stands  for  1000)  have 
been  used  in  print  in  more  than  10,000 
articles  and  books  since  1946  Most  users  of 
LOC  and  KLOC  regard  this  metric  as  being 
objective,  and  indeed  a  number  of  standard 
reference  books  and  articles  on  metrics  have 
cited  the  objectivity  of  LOC  as  a  key  virtue. 

However,  from  discussions  with  more  than  a 
thousand  software  managers  and 
professionals,  it  is  unfortunate  to  report  that 
the  LOC  metric  may  be  the  most  subjective 
metric  used  in  refereed  articles  in  the  last  50 
years. 

When  LOC  and  KLOC  originated  as 
software  metrics,  the  only  languages  in  use 
were  machine  language  and  basic  assembly 
language.  For  basic  assembly  language, 
physical  lines  and  logical  lines  were  equal: 
each  source  statement  occupied  one  line  on  a 
coding  sheet  or  one  tab  card.  From  1946 
until  about  1960,  LOC  and  KLOC  metrics 
were  reasonably  well  defined  and  reasonably 
objective.  The  explosion  of  languages  from 
1960  forward  destroyed  the  objectivity  of 
LOC  and  KLOC,  and  their  validity  for 
economic  studies  as  well. 

From  surveys  of  counting  practices  carried 
out  by  the  author  and  his  colleagues  at 
Software  Productivity  Research,  the  varieties 
of  subjective  methods  associated  with  LOC 
counting  creates  a  total  range  of  apparent 
size  of  more  than  one  order  of  magnitude  for 
the  software  industry  as  a  whole.  The 
largest  number  of  major  code  counting 
variations  observed  within  a  single  company 
was  six,  and  the  range  for  counting  the  size 
of  a  single  control  project  within  that 
company  was  approximately  5  to  1 .  This  is 
far  too  broad  a  range  to  be  tolerated  for  an 
engineering  metric. 
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The  standard  dictionary  definition  of 
subjectivity  is  "Particular  to  a  given 
individual,  personal."  Under  that  definition,  it 
must  be  concluded  that  LOC  and  KLOC  are 
in  fact  subjective  metrics  and  not  objective 
ones. 

Code  counting  subjectivity  could  be 
eliminated  by  establishing  standard  counting 
conventions  for  each  major  language. 
Indeed,  Software  Productivity  Research  (2), 
the  IEEE  (3),  and  the  Software  Engineering 
Institute  (4)  published  preliminary  draft  LOC 
counting  proposals  within  a  year  of  one 
another. 

Unfortunately,  the  SPR,  IEEE,  and  SEI  draft 
standards  differ,  so  even  in  the  domain  of 
standardization  of  LOC  counting  practices 
subjectivity  is  present.  Note  that  for  many 
modem  languages  such  as  4GL's, 
spreadsheets,  query  languages,  object- 
oriented  languages,  and  graphics  icon-base 
languages,  none  of  the  current  draft 
standards  are  technically  acceptable. 

The  LOC  Paradox 


embarrassing  for  a  major  industry  such  as 
software  to  continue  to  use  a  metric  that 
does  not  work,  and  to  do  so  without  even 
realizing  what  is  wrong  with  it! 

Unfortunately,  many  well-known  books  on 
software  measurement  and  economics  do  not 
contain  even  a  single  statement  about  this 
well-known  problem.  To  cite  but  two 
examples,  both  Barry  Boehm's  Software 
Engineering  Economics  (5)  and  Robert 
Grady's  and  Deborah  Caswell's  Software 
Metrics:  Establishing  a  Company-Wide 
Program  (6)  use  LOC  and  KLOC  metrics 
without  any  warnings  or  cautions  to  the 
readers  of  the  paradoxical  nature  of  these 
metrics  for  high-level  languages. 

Unfortunately,  the  software  measurement 
initiatives  at  SEI  (7)  also  fail  to  discuss  the 
problems  and  paradox  of  LOC  metrics,  and 
do  not  discuss  functional  metrics  at  all. 
These  unfortunate  omissions  place  the  SEI 
measurement  work  some  distance  behind  the 
state  of  the  art,  although  other  aspects  cf  the 
SEI  measurement  studies  are  fairly 
advanced. 


The  LOC  and  KLOC  metrics  have  a  much 
deeper  and  more  serious  problem  than  a 
simple  lack  of  standardization:  LOC  metrics 
are  troubled  by  a  deep  mathematical 
paradox.  Both  productivity  and  quality 
appear  to  move  backwards  when  measured 
with  LOC! 

Indeed,  the  tendency  of  LOC  and  KLOC  to 
move  backwards  as  economic  productivity 
improves  is  a  much  more  serious  problem  for 
software  economic  studies  than  the 
subjectivity  of  LOC  and  KLOC.  This 
mathematical  problems  with  LOC  are  severe 
enough  so  that  they  make  the  phrase 
"software  engineering"  seem  ridiculous.  It  is 


The  paradox  with  LOC  and  KLOC  is  caused 
by  the  impact  of  the  fixed  and  inelastic  costs 
of  certain  activities  that  are  always  part  of 
software  projects.  The  problem  of 
measuring  productivity  in  the  presence  of 
fixed  costs  has  long  been  understood  for 
manufacturing  economics. 

However  for  software,  it  was  initially 
described  by  the  author  in  1978  (8),  and  fully 
explained  in  1986  in  the  book  Programming 
Productivity  (9). 

There  is  a  basic  law  of  manufacturing 
economics  that  if  a  manufacturing  process 
includes  a  high  percentage  of  fixed  costs,  and 


llth  Annual  National  Conference  on  Ada  Technology  1993 


210 


the  number  of  units  produced  goes  down, 
the  cost  per  unit  will  go  up.  This  same  law 
also  applies  to  software.  When  LOC  is  used 
as  a  manufacturing  unit,  and  there  is  a  move 
from  low-level  to  high-level  languages,  then 
obviously  the  number  of  "units”  to  be  created 
will  decline  in  the  presence  of  fixed  costs. 

Using  LOC  and  KLOC  metrics  for  a  single 
language  can  produce  valid  results  if 
standard  counting  rules  are  applied. 
However,  for  cross-language  comparisons, 
or  for  projects  containing  multiple  languages 
(such  as  Ada  and  Assembly)  the  results  are 
always  invalid  and  paradoxical. 


for  multi-language  studies.  Following  are 
situations  where  LOC  and  KLOC  are 
ambiguous  enough  to  be  harmful  to 
economic  understanding  .  and  their  usage 
should  constitute  malpractice: 

A)  LOC  and  KLOC  metrics  should  be 
avoided  for  economic  studies  involving 
object-oriented  languages,  4GL's, 
generators,  spreadsheets,  and  graphic-icon 
based  languages. 

B)  LOC  and  KLOC  metrics  should  never  be 
used  to  compare  unlike  languages,  such  as 
C++  and  Ada. 


The  LOC  metric,  compared  to  Function 
Points,  also  distorts  quality  measurements. 
The  situation  with  LOC  is  so  paradoxical  and 
absurd  in  the  presence  of  high-level 
languages  that  it  is  fair  to  state  that  the  LOC 
metric  has  slowed  the  advance  of  software 
engineering  as  a  true  engineering  discipline. 
It  is  time  to  step  up  to  this  problem,  and 
declare  LOC  metrics  to  be  an  example  of 
professional  malpractice. 

Malpractice  is  a  serious  situation,  and  implies 
the  usage  of  an  approach  known  to  be 
harmful  under  certain  conditions,  which 
should  have  been  avoided  through  normal 
professional  diligence.  For  example,  a 
medical  doctor  who  prescribed  penicillin  for 
a  patient  known  to  be  allergic  to  that 
antibiotic  is  an  illustration  of  professional 
malpractice.  Using  LOC  and  KLOC  metrics 
to  evaluate  languages  of  different  levels 
without  cautioning  about  the  paradoxical 
results  that  occur  is  unfortunately  also  an 
example  of  professional  malpractice. 

The  LOC  and  KLOC  metrics  grow 
progressively  more  ambiguous  and  counter¬ 
intuitive  as  the  level  of  languages  goes  up  or 


C)  LOC  and  KLOC  metrics  should  not  be 
used  for  applications  containing  multiple 
languages,  such  as  C  and  Assembly  or  Ada 
and  Assembly. 

D)  LOC  and  KLOC  metrics  should  not  be 
used  to  measure  Software  plans, 
specifications,  or  Other  non-code 
deliverables. 

E)  LOC  and  KLOC  metrics  should  not  be 

used  for  quality  normalization  (i.e.  defects 
per  KLOC)  for  studies  involving  multiple 
languages.  | 

Consider  the  similar  problem  of  carrying  out 
international  cost  surveys  that  involve 
multiple  currencies  such  as  dollars,  yen, 
pounds,  lire,  deutschmarks,  francs,  etc. 

There  are  two  methods  for  Carrying  out 
accurate  international  cost  surveys:  A)  One 
of  the  currencies  such  as  dollars  is  selected 
as  the  base  currency,  and  all  other  currencies 
are  converted  into  equivalent  amounts;  2)  A 
synthetic  base  metric  such  as  European 
Currency  Units  (ECU)  is  selected,  and  all 
quantities  are  expressed  in  those  units. 
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Now  consider  the  same  project,  only  let  us 
assume  that  the  programming  language 
used  was  Ada: 


The  acceptable  methods  for  dealing  with 
multiple  currencies  provide  a  useful  model 
for  software  studies  dealing  with  multiple 
languages: 


Ada  Language  Version 
(2,000  LOC  and  50  Function  Points) 

Activity  Effort  Costs 


A)  One  of  the  languages  such  as  Assembly 
Language  is  selected  as  the  base  language, 
and  all  other  languages  are  converted  into 
equivalent  amounts. 


B)  A  synthetic  base  metric  such  as  Feature 
Points  is  selected,  and  all  quantities  are 
expressed  in  those  units.  Of  these  two 
methods  for  dealing  with  multiple  languages, 
method  B  is  preferred  today. 


Requirements 

2.0 

$20,000 

Design 

2.0 

$20,000 

Coding 

1.5 

$15,000 

Testing 

1.5 

$15,000 

Documents 

2.0 

$20,000 

Management 

1.0 

$10,000 

Totals 

10.0 

$100,000 

Since  the  Ada  language  is  such  a  key 
component  of  military  software  strategy,  it 
is  important  to  understand  the  way  LOC 
metrics  interact  with  Ada. 

Following  are  two  abstract  examples  of  the 
same  project,  with  one  version  created  in 
Assembly  Language  and  the  other  in  the 
Ada  language,  to  clarify  the  paradox  of 
LOC  metrics. 

Assembly  Language  Version 
(10,000  LOC  and  50  Function  Points) 


Activity 

Effort 

Costs 

Requirements 

2.0 

$20,000 

Design 

4.0 

$40,000 

Coding 

6.0 

$60,000 

Testing 

4.0 

$40,000 

Documents 

2.0 

$20,000 

Management 

2.0 

$20,000 

Totals 

20.0 

$200,000 

Using  standard  economic  definitions,  the 
Ada  version  is  twice  as  productive  as  the 
Assembly  language  version,  since  the  same 
goods  were  delivered  with  only  half  the 
effort  and  expense. 

However,  when  productivity  is  measured 
using  manufacturing  economics,  with  LOC 
defined  as  the  unit  of  manufacture,  the  real 
economic  advantages  of  Ada  cannot  be 
seen: 

LOC  per  Cost  per 

Staff  Month  Source  Line 

Assembly  500  $20.00 

Ada  200  $50.00 


When  the  manufacturing  unit  is  switched 
from  LOC  to  Function  Points,  the 
economic  advantages  of  Ada  become  clear. 
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Since  both  versions  perform  the  same 
functions,  assume  that  the  Function  Point 
totals  of  the  Assembly  and  Ada  versions  are 
identical:  50  Function  Points  each. 


FP  Per 

Cost  per 

Staff  Month 

FP 

Assembly 

2.5 

$4000 

Ada 

5.0 

$2000 

Observe  that  when  Function  Points  are  used 
as  the  unit  of  manufacture,  rather  than 
Lines  of  Code,  standard  economics  and 
manufacturing  economics  now  agree.  Ada 
is  significantly  more  productive  than 
Assembly  language. 

Function  Points  are  synthetic  metrics,  and 
one  of  the  advantages  of  synthetic  metrics 
is  that  they  have  wide  general  utility.  For 
example,  the  synthetic  metric  horsepower 
can  be  used  on  electric,  diesel,  and  gasoline 
engines  with  equal  precision. 

Natural  metrics,  such  as  LOC,  cause 
serious  trouble  when  they  are  used  outside 
their  normal  domain.  In  the  case  of  LOC, 
it  the  inclusion  of  non-coding  activities 
which  degrade  their  accuracy. 

Data  from  the  MK-160  Gun  System 

The  basic  thesis  of  this  paper  is  that  coding 
is  no  longer  the  dominant  cost  driver  for 
military  software  projects,  and  other 
elements  such  as  paperwork,  testing,  and 
non-coding  tasks  now  constitute  the  bulk  of 
military  software  costs. 

If  coding  is  only  a  minor  portion  of  total 
software  costs,  then  it  is  inappropriate  to 


use  LOC  metrics  for  the  entire  project. 
Synthetic  metrics  such  as  Function  Points 
are  much  more  appropriate  for 
normalization  of  mixed-activity  economic 
and  quality  studies. 

It  is  useful  to  conclude  by  examining  actual 
data.  A  report  on  the  MK-160  gun 
computing  system  produced  by  Paul  W. 
Lusher  of  the  Naval  Surface  Weapons 
Center  at  Dahlgren  (10)  provides 
confirmation  of  the  hypothesis  that  coding 
is  no  longer  the  dominant  cost  driver  for 
military  software  applications. 

The  MK-160  is  a  mixed-language  system 
written  primarily  in  CMS2  and  containing 
about  120,632  LOC  and  1240  Function 
Points. 

The  sum  of  the  plans,  specifications,  and 
user  documents  for  the  project  totaled  to 
5,585  pages. 

The  total  effort  for  the  project  was  795.6 
person  months. 

Coding  itself  constituted  221.5  person 
months,  or  only  27.8%  of  the  total. 

Activities  concerned  with  paperwork 
(plans,  specifications,  user  documents) 
amounted  to  256.8  person  months,  or  about 
32.3%  of  the  total. 

Activities  concerned  with  defect  removal 
operations  (reviews,  inspections,  testing) 
amounted  to  200.1  person  months  of  effort, 
or  about  25%  of  the  total. 

The  effort  for  the  various  non-coding 
activities  associated  with  this  project  far 
outweighed  the  code-related  activities: 
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about  72.1%  of  the  total  effort  went  on 
non-coding  activities. 

Following  are  some  of  the  details  of  this 
project,  to  illustrate  the  mixture  of  coding, 
paperwork,  defect  removal,  and  other 
activities  which  comprise  modem  military 
weapons  software: 


Software  Effort  for  the  MK-160  Gun 
System 


Activity 

Person  Months 
Effort 

Development  plan 

5.7 

Test  plan 

6.9 

Personnel  management 

91.4 

Progress  reports 

25.4 

Configuration  control 

25.7 

Requirements 

58.4 

System  architecture 

11.3 

Initial  specification 

65.3 

Final  specification 

23.6 

Data  design  spec 

23.1 

Data  structure  review 

4.5 

Coding 

221.5 

Unit  test 

14.6 

Function  test 

21.3 

Regression  test 

7.9 

Integration 

14.7 

Integration  test 

18.5 

Stress  test 

10.4 

System  test 

31.6 

Field  test 

23.1 

Independent  test 

23.7 

Operator's  guide 

12.2 

Maintenance  manual 

21.9 

Reference  card 

0.2 

Total 

795.6 

The  overall  productivity  rate  for  this 
project  expressed  in  LOC  is  about  152 
LOC  per  person  month  (note  that  pure 
coding  had  a  rate  of  about  545  LOC  per 
person  month). 

Expressed  in  Function  Points  per  person 
month,  the  overall  rate  was  1.56,  and  the 
coding  itself  had  a  rate  of  about  5.6 
Function  Points  per  person  month. 

For  mixed  language  projects,  and  for 
comparison  between  projects,  Function 
Points  are  maikedly  superior  to  the  older 
LOC  metrics  for  all  normalization, 
economic,  and  quality  research  purposes. 

Summary  and  Conclusions 

Software  development  in  1993  is  changing 
dramatically  under  the  combined  impact  of 
new  languages,  new  standards,  new  tools, 
and  new  methods. 

In  order  to  explore  the  impact  of  these  new 
approaches,  it  is  urgent  for  the  software 
industry  ~  both  military  and  civilian  —  to 
be  able  to  measure  the  impact  of  improved 
practices. 

Lines  of  Code  metrics  are  no  longer  viable, 
and  indeed  a  case  can  be  made  for 
relegating  LOC  metrics  to  the  category  of 
"professional  malpractice." 

Modem  functional  metrics  are  becoming 
the  dominant  tool  for  exploring  software 
productivity  and  quality  as  the  industry 
matures. 

Indeed,  the  non-profit  International 
Function  Point  Users  Group  (IFPUG)  has 
been  growing  at  a  rate  of  46%  per  year  and 
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is  now  the  largest  measurement  association 
in  the  United  States. 

it  is  critical  that  the  software  measurement 
work  of  the  U.S.  military  services,  the 
DoD,  and  the  Software  Engineering 
Institute  (SEI)  be  at  state  of  the  art  levels. 

This  means  that  the  basic  concepts  of 
functional  metrics  should  now  be  included 
in  the  training  of  software  engineers  and 
software  managers. 
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